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
- Having same-named types, sharing the JCas cover types for those, but (after merging) having different sets of features.
- This would only be used for UIMA (merged) Types that have same name but have different feature sets.
- Current design uses the same JCas cover class for differing type systems (e.g., ones that have a different # of features for a type). In this case, the JCas cover type only is being used to set/read slots it knows about; other facilities might be used to read/set additional slots.
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
Supporting Java 8 streams
Iterating over FSs: alternative: have generator of FSs, process with stream APIs
- Possibly having a new kind of managed component? being either
- The "functions" the standard operations on streams use
- new standard operations on streams (unlikely I think)
- I think this might be deferred until we have some more experience
(Unlikely) Making the element of the "stream" be a new CAS - replacement for CAS Multipliers. Seems like the wrong granularity... Maybe best to let Java evolve this for a few more releases.