...

1. The Built-in classes are loaded and initialized at the first type system commit.
   
   1. These are loaded using the ClassLoader used to load the UIMA framework
   2. On subsequent type system commits, the built-in classes are not reloaded.
2. Other non-Pear JCas classes are loaded at type system commit time.  The  
   1. The classes may have already been loaded (by other type systems)
   2. The classes are loaded with respect to that type system and a particular extension class loader (if present).  
3. Pear JCas classes are loaded when a Pear's ClassLoader is inserted into the environment for the first time, for a given type system.
   1. Pear JCas classes are reloaded if the type system changes - because additional types may cause additional JCas classes to be loaded.

...

Design considerations (older thoughts)

• Built-in types support - would be nice if these were not needlessly replicated - this is done by sharing the built-ins
• Within a single JVM, there may be multiple UIMA type systems actively in use.  This  This is most likely supported via a separate class loader for these
  • This implies that the code which uses objects under the class loader be loaded from the same class loader; otherwise they can't "see" the loaded classes.
  • V2 UIMA may (optionally) make use of the UIMAClassLoader with a user-supplied class path, which doesn't delegate to the parent first - it checks its own classpath first,
    • This happens when the UIMA app specifies a UIMA extension class loader (via a not-well-documented method on a ResourceManager instance, setExtensionClassPath)  or a Data Path.
    • It's unlikely that most user code makes use of this.
    • The PEAR classpath isolation makes use of this. 
  • V3 augments the UIMAClassLoader with
    • the capability to recognize and generate JCas classes
      • This requires the loader have an association with one (or more?) particular committed type system instance, in order to do the proper generation.
• A single type system may be used (via UIMA application APIs) for multiple different pipelines, and for multiple different sets of index definitions.
  • Having a single type system for multiple different sets of index definitions is unlikely
  • The index definition supplies the avoid-index-corruption information needed by the setters
    • If supplied at JCas generation time, then the test can be inserted only where needed, rather than run time testing if it is needed for many types. Test is currently a Bitset lookup.
      • Not done because JCas definitions used for multiple type systems, multiple pipeline definitions
• Managing multiple type systems actively in use in a single JVM
  • It is possible to do this using Servlet-style complete class loading isolation
    • Done outside of the UIMA framework (but within the single JVM, e.g. Servlet-style class loading)
    • UIMA Impl classes and UIMA pipeline application classes loaded under multiple separate loaders (multiple copies)
    • Works for generated JCas classes, nothing special needed
  • UIMA framework managing multiple type systems
    • UseCase 1: a single pipeline being used, sequentially, for multiple type systems
    • UseCase 2: running multiple pipelines (in parallel) with different type systems, each of which might exhibit UseCase 1.
    • UseCase 1 in v2:  If the JCas isn't being used, then there's no class loading issue. This case can arise when deserialization is being used, and each CAS has its own (potentially different) type system.  The user code might be making use of what it a priori knows to be "common" types and features among the different deserializations.  (For example, all the built-in types are common).
      • The user code could reference non-common features, after using some other value to get the name of the feature.
      • If the JCas is in use, this is supported if the JCas generation was done with the specified feature, and that feature is present.  This requires that the JCas implementation check if the feature being accessed is defined in the current type system; an exception is thrown otherwise.
    • UseCase 1 in v3: 
      • For a given class loader, the generated JCas types cannot be updated.  (Well, there is a non-performant way, via another indirection - some fancy systems use to allow runtime redefinition of classes - see for instance http://zeroturnaround.com/software/jrebel/ or various other methods (google java runtime redefinition classes reload ).
        • Approaches: 
          • The generated types on the first deserialization need to have the Union of all expected types. This might require creation of the Union Type System, via an external utility, and an API for specifying that to UIMA.  This could also cause some inefficiencies, because the Union could grow large.
          • The classloader used needs to be "dropped" and a new one substituted - this will cause regeneration of JCas classes particular to the deserialized type system, but also cause reloading, re-JITting, etc. all the implementation classes of the pipeline.
          • Use "trampoline" FS
    • UseCase2 in v2: If the JCas isn't being used, then there's no class loading issue 
      • except for potential collisions due to same-named annotator / external resource classes with different implementations.
        • Can be avoided by user using UIMA Extension Class Loaders or UIMA DataPaths, per pipeline
      • If the JCas is in use, then
        • If a common classloader is being used, then the JCas definition must be for the Union of the used parts (via JCas) of the type systems.
        • If a separate classloader is being used, then there is no constraint on the JCas definition being used.  
    • UseCase2 in v3:
      • If a common classloader is being used, then the JCas definition must be for the Union of all types/features of the used type systems.
      • If a separate classloader is being used, then there is no constraint, as above. 

...

Things below are old ideas, not chosen, not done

Alternative to generated JCas classes to avoid classloading issues

...