Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • To get around "reflection" slowness: 
    • Support set/get by int <- class <- feature-name-string
    • Support set/get (bulk) ? <ordering among fields significant?>
    • possibly use something like ReflectASM which is like Java reflection but has a byte-code generator and is much faster (but probably not as fast as custom support code compiled into the Java Cover class).

Problem with use-case of changing TypeSystems

This has one serious issue, not yet solved, illustrated by the use case: 

  1.  make a pipeline, 
  2. deserialize some CAS's type system, and then deserialize that CAS
  3. do some generic processing on that CAS
  4. repeat 2 and 3 in a loop, with different type systems each time.

Setting up the merged type system and generating the Java class definitions means that those classes might need to be replaced, but they might be linked to the existing code.

Data Model (Types and Features) adapters

...

Currently users may customize their JCas cover classes.  PEAR classpath isolation allows the use case where different customizations are present in one pipeline.  The current implementation supports this, and switches the set of JCas cover classes as Pear boundaries are crossed.  The idea of a Feature Structure being an instance of its cover class breaks down when multiple definitions of this exist.  Some ideas for fixing this.

Support parallel execution of components (if they don't depend on each other)

...