Page History

...

• 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 name clash with existing non-JCas class

There are use cases where JCas cover classes are not being used for some classes, yet the users define a class named identically to a JCas cover class.  This is permitted in UIMA v2. 

For example, you could have a class x.y.z.ConceptType which was defined as a Java enum.  You could also have a UIMA type, x.y.z.ConceptType, and work with it without using JCas APIs.

One possible approach is to map the uima type name to a special java class name for these use cases so there's no collision; of course, the user would need to use the non-JCas APIs for this type. 

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.

Alternatives: generating JCas definitions from merged type systems

There are two approaches - more dynamic and less dynamic. 

• Have a separate step, run outside of the UIMA runtime environment, which generates the full set of JCas classes (except the built-ins), from the merged type system
  
  • Configure the JVM classpath to include these classes typically at the front of the classpath.
• Have an integrated approach, based on classloaders, that generate classes at type system merge (or lazily) and load them either all at once or via a special version of UIMAClassLoader, lazily.

More here.

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

...