You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

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.

  • No labels