A place to collect ideas for the next version of UiMA Java core.
Big changes
More use of Java compiler (ecj) and decompiling
A portable Java compiler from Eclipse (ecj) and decompiling capabilities (e.g. Procyon) are appropriately licensed and could be part of the startup.
- JCasGen could be "automatic" for merged type systems, and merged instances of JCasGen'd user classes?
- Users still would need a generated version for their code to compile against.
- Pear definitions for JCas cover classes could be merged?
- Could generate one kind of Java cover class for all types. (lazy, load on demand
- eliminate / reduce use of TypeImpl in runtime.
- generate for all merged types (except custom built ins)
- (as opposed to current impl, where no JCas cover class is generated if it doesn't exist - the "standard" one is used instead)
- use class loader technology to support multiple type systems.
- only for class definitions that have same name but are different.
Feature Structure == an instance of its Java Cover class
One representation only of a FS; the static fields of the class have the typeImpl info..
Features represented directly as fields.
- To get around "reflection" slowness:
- Support set/get by int <- class <- feature-name-string
- Support set/get (bulk) ? <ordering among fields significant?>
More concurrency
Support parallel running of pipeline components.
Careful trade-off vs slower due to synchronization, cache-line interference. Key is to separate things being updated.
Consider special index support for this