Page History

...

There is a generic Java class for these, plus (optional) specific classes for JCas style access. 

xxx_Type files

These are eliminated in v3.  They served 2 purposes:

1. save one slot per feature structure - instead of a casImpl ref and a typeImpl ref, there was just one ref to the _Type instance, which in turn, and these two refs
2. provided a place for the low level accessors.

It's unclear if anyone is using the low level accessors.  These may be retained, but moved to the main xxx classes.

For the non-JCas style of Java cover classes (FeatureStructureImplC) these did not implement a _Type instance, and had as a consequence both a casImpl ref and a typeimpl ref.

JCas Class generation

JCas cover classes now come in pairs; the base cover class and one with a name formed from the base by appending _Type (same as V2).  These in single classes, rather than in pairs.  These classes are either built-in or are generated.

...

; built-in ones cannot be generatedhas a ref to the CAS view.  A single class definition might be used for multiple type systems; a single definition is used for all the built in types.  Each JCas class extends

• has a ref to the corresponding TypeImpl.  This can't be in the main class as a static, as there is a one-to-many relationship because the built-in main classes are shared across type systems.

When generated, they are specific to one (merged) type system, except for shared, common, built-in class definitions.  To allow for multiple type systems within one JVM simultaneously, class loader isolation is used.

...