Page History

...

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

User customization of Java cover classes, and PEAR classpath isolation issues

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 include:

• Do some kind of "merge" operation among all definitions of JCas cover classes including those in contained PEARs, and use that one merged definition everywhere.  This has drawbacks, such as - it's not always possible to find a merge that preserves all the original implementations.
• Split apart the system-generated (from the merged type system) JCas cover class and user customization, into different classes.  The user customization class would wrap the system-generated one, and create both; all value setting/getting would be via forwarding methods.  
  • Advantages: 
    • No merging logic is needed; it would allow dropping the merge facility (which is old, doesn't support Java 1.5 or later, etc.)
    • The system could autogenerate from the merged type system a cover class that supported all the fields, properly, making full use of the type hierarchy.  There would be no need to have external processes or procedures to insure that the cover class generated had the fully merged type system; this would be automatic.
    • Better management of customization vs system code due to their separation.  
  • Disadvantages: 
    • It would require some kind of a migration utility, because this is not how users customized the generated classes.
    • It would end up with one more re-direction for get/set operations (due to the wrapper), for customized classes
  • Nesting: An "outermost" pipeline can nest 1 or more PEARs, which, in turn may nest one or more inner PEARs, etc.

More concurrency

Support parallel running of pipeline components.

...