Page History

...

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.
elimiated?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.

...

To get around "reflection" slowness:
- Support set/get by int <- class <- feature-name-string
- Support set/get (bulk) ? <ordering among fields significant?>

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

Versions Compared