UIMAJ v3 PEAR Support

This page discusses ideas for supporting PEAR classpath isolation with "customized" JCas cover classes.

The problem arises because with the Feature Structure data contained solely in a particular instance of a Java class, there must be an approach to have the differing contexts (different PEAR definitions of the customization of the JCas cover class) share and update this data.  An instance produced from a PEAR needs to be able to be used outside of the PEAR, and vice-versa. 

Merge all the custom definitions into one and use that everywhere.

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.  

• Advantages: is most similar to what we have now
• Disadvantages: it's not always possible to find a merge that preserves all the original implementations.  It might be very difficult to construct an appropriate merge algorithm, given the arbitrariness of the custom code.

Keep the system-generated code in one class, and use a different wrapping class for the customization

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 generate from the merged type system a cover class that supported all the fields, 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.  Projects could run JCasGen to get prototype cover classes - these would not be loaded but would serve to provide classes to have code compile against. 
• Better management of customization vs system code due to their separation.  

Disadvantages: 

• This approach seems to break the type inheritance model (a custom class wrapping the system-generated one would not be in a Java type hierarchy.  The normal way around this is to have "interfaces" in the hierarchy.  However interfaces can be created with "new ...".  I suppose we could change things to not rely on "new" (e.g., have a create() operator). But that would be a big change.
• 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.  If no customization was needed, the generated class would be named with the official name and serve all uses of it. 

Nesting: An "outermost" pipeline can nest 1 or more PEARs, which, in turn may nest one or more inner PEARs, etc.  (Type merging is applied to all the type definitions, including those in the PEAR). Each inner PEAR JCas customization would be a 1-level wrapper of the system-generated class from the outer-most pipeline (not on its container if it was a PEAR).

Naming: JCas cover classes are named to match their UIMA type name.  This enables users to write "new MyType()" where MyType is the UIMA type name.  

• If a JCas cover class is not customized (anywhere in the pipeline, including inside PEAR files), we have the system generated class, and its expected name as it is now.  
• If it is customized, the custom "wrapper" would carry the official name, so users would use it, and the system-generated class would need a new name (e.g. xxxx_UIMA_JCas_Generated.), which would "hide it" from normal access.  A complete analysis of the pipeline running as an application in one JVM would be needed to find (including inside PEARs) which UIMA types had customization (anywhere, including even if in just one PEAR).  Those types would need the alternate naming protocol. 

Keep the system-generated code in one class, and do the customization in a class "extension"

Another way to split apart the system-generated from the customization: have the customization "extend" rather than wrap the system-generated one.

Advantages

• Type hierarchy / inheritance works (sort of).  

Disadvantages

• If you extend a class to cusotmize it, and some classes in the parent chain are also extended, your extended class misses those customizations.  (This is avoided if you instead "merge").