...

• The instances of these classes are the feature structure; the feature values are stored in fields
  • Uima types which have natural corresponding Java equivalents have feature values stored using the natural corresponding Java types
    • primitives:  boolean, byte, short, int, long, float, double, String, \[arbitrary-java-objects] and arrays of these as xxx[].
• Most UIMA built-in types have standard defined Java class definitions.

...

• • Except for some built-in values like arrays, UIMA features are stored in either a hidden int[] field or a hidden Object[] field.

Environment Possibilities - Type Systems, Class Loaders, UIMA Instances

Users use UIMA in many different use cases.  Two major classes of use cases are:

1. A single type system shared by multiple sets of JCas classes for the same type (PEAR class path isolation, and multiple pipelines running with different extension class paths)
2. A single set of JCas classes, used for multiple type systems (an application where a processing loop includes deserializing the next type system + CAS, and processing it in some way)

This discussion assumes the core UIMA framework was loaded under 1 class loader, and is managing potential multiples of type systems and JCas class sets.  

Of course, it is also possible to have multiple core UIMA frameworks loaded under different class loaders - for example, running multiple frameworks in a web server application.  These kinds of deployments typically isolate each running application from one another.

JCas classes, once loaded under some particular class loader, cannot be unloaded (unless no references exist to them and the class loader used to load it, itself, is GC'd).

Because of this, there are constraints on the use case having multiple type system sharing one set of JCas classes (case 1 above).  If a need exists to get around these constraints, then an approach using additional isolating class loaders must be employed by the user's application.

When a set of JCas classes is loaded, it is required that some associated committed type system be present.  This type system may contain a subset or superset of the types defined in the JCas set.  The type system is used to provide the feature offset constants set as final static values in the JCas loaded class.

It is possible that the class has already been loaded, perhaps using a different associated committed type system.  A check is done to insure that the type system's offset values for features matches what is set as static final values in the loaded class; this is a constraint that must be met when switching type systems while using JCas classes.

...