...
The performance reason for using the low level accessors is not present in V3; in fact, these, if implemented, would be slower than the other APIs.
JCas Class sharing
JCas cover classes now come in single classes, rather than in pairs. These classes are either built-in or are generated; built-in ones cannot be generatedJCas classes are associated with a class loader. Except for the built-in types which always have JCas Classes, other JCas classes are optional. Furthermore, JCas classes may define only a subset of the features of the fully merged type system. So, even when a JCas class is present, it may not have getters and setters for some features of the corresponding UIMA type. These features can be accessed of course using the plain APIs (see above).
...
It is possible to run multiple pipelines with non-compatible type systems and JCas classes by running each one under its own class loader; in this scenario, each pipeline will load its own copy of JCas classes from its own classloader's classpath.
JCas Class and UIMA Type conformance
JCas Classes have static final fields computed at load time. Each type system commit loads corresponding JCas classes (the load only happens the first time, per class loader).
A particular type system instance is being committed when a JCas class is loaded. At load time, these rules are checked:
- Construct the supertype chain of the class being loaded. It must be the case that, scanning upwards, there is a supertype that has a corresponding UIMA type.
- It is OK if there are UIMA types between this and the found corresponding supertype - that just means there were no JCas types defined for those.
- It is OK for the supertype chain to pass through supertypes which are not UIMA types, as long as the JCas supertypes are abstract (can't be instantiated)
- For each feature
- the feature offset assigned to the class's static final value must match the feature offset
- the feature's range must match
- JCas-defined features which do not exist in the 1st type system loading this JCas class will result in invalid getters and setters for that feature, if an attempt is made in some code to get/set those features.
How JCas feature offsets are computed or validated at type-system-commit time
The type system is walked in subsumption order, and offsets are assigned to all features. Then the JCas classes are loaded - the corresponding features are used to set the static final int offset values in the JCas class, if they are actually loaded. If they are already loaded, the existing values are checked to insure that they match the type system assigned values. A mismatch can occur if multiple different type systems are being used. Mismatches (which cannot happen if only one type system is in use) result in a fatal error.
Connecting Instances with Type and Feature information
...