Page History

...

• What happens when a type system changes?  Some ways this might occur:
  • CAS reinitialized due to restoring a persisted (binary/serialized) CAS.  
    • Two sub-cases:
      • The app/externalresource/annotator code has references by name to the generated JCas classes (e.g. they code "myFooInstance.getMyFeature()".
        • If this code was executed, the lazy loading and linking of Java would have linked the (e.g.) annotator reference to the class.  Java doesn't support "unlinking" in general, so the only way I see to handle this case is to create a new UIMATypeSystemClassLoader for the new type system (assuming it was different of course), and reload/relink new versions of the classes to connect with the new definitions of the JCas classes.
      • If there are no ref-by-name, then maybe (to be determined) we can redefine the class.  The APIs are there, it just depends if this is allowed.  This would be a case where the type system was thought to be "variable", so the code could actually not really have by-name references (other than, say, to built-in types, whose definition is imagined to be shared in any case). 
  • New types defined at runtime
    • either externally by an application (already possible), or internally by an AE while a pipeline is running (a potential new feature being discussed)
    • These would, I think, always be referenced via some kind of indirection, not by a Java-linked name.  For the moment, I was thinking that since the new JCas would support Java HashMaps, that this requirement could be met by implementing a map from a user-specified key (e.g., a string) to a value; these could be constrained using Java generics.  This would be an initial way to support this requirement; we could later investigate more native ways.
• is JCas the only option or is a basic CAS API still available?
  • The intent is to allow existing users of UIMA to run their pipelines in V3, as much as may be feasible.  So, yes, I think we should continue to support the following CAS and JCas api varieties:
    • JCas - creation via new operator, getters/setters for each field, array getters/setters for array-valued fields
    • So called low level JCas (makes use of the _Type class)
    • CAS Apis - use Feature objects to specify the feature, and have variety for the various range types.  (Probably will add "array" styles, which are currently missing I think).  This API doesn't use by-name java-linked references.  As of Java 8, there is a significant improvement to the compiler + JVM that makes this style just as efficient as the by-name linked style.
    • Low-level CAS Apis
• To what extend can users in the new design customize JCas classes? If they are generated at runtime, no customization may be possible anymore.
  • The intent is to continue to allow users to customize JCas classes.  See JCasClassLoading
  • This isn't prototyped yet.  But the expectation (hope?) is that the bytecode can be examined and merged as appropriate from the customized classes.
• One's One expectations towards a more native JCas is the ability to store arbitrary objects in the CAS, potentially in customized JCas classes. Is this part of the new design? If yes, how to preserve such objects when a classloader changes and JCas is regenerated?
  • The main idea is that on regeneration, there's a "merge" step from any customizations that might be present in the classpath.
  • Another goal is that because the new V3 design has a new kind of range type for Features, called "JavaObject", which I hope will turn out to be able to hold arbitrary Java Objects (although we might limit this initially), this will allow storing arbitrary Java objects in the CAS as the values of particular features, without any customization.  

Setup for Type System class loader

...