Merging the JCas Cover Class and its _Type class

This page has design notes for merging the Xyz and Xyz_Type classes generated by JCasGen, and changes to the JCasImpl needed to support this.

Basic design and Goals

Goals

• New JCasGen generated code generates 1 class instead of 2, per type
• The merge operation works even when the original is 2 classes.
• Old JCas generated cover classes having 2 classes per CAS type still work (backwards compatibility)
• Allow Users to specify which style of class generation they want out of JCasGen

  The reason for this is because some users may have designs which subclassed the JCasGenerated classes, and this might break their code, needlessly.

Basic design

The basic idea is to have one source file for both the Xyz and Xyz_Type classes. The methodology is to have the _Type class be a static inner class of the Type class.

Then the JCas initialization code would be modified to try and load the _Type (as it does now, for backwards compatibility) as well as the Xyz$Xyz_Type which would be the new name. Or perhaps we could avoid directly loading the _Type, and just have the loading of the Xyz class cause the loading of the other (I think there is some issue here, though).

Access to the _Type object

It seems that the user can still get access to the _Type class instance for a particular type and (j)cas by doing
(MyParticularType_Type)aJCas.getType(MyParticularType.type). The import for this _Type would reference the outer class.innerclass_Type.

Built-ins and Supertypes

We need to keep existing JCas cover classes for existing types in the current format of two separate classes, to support old code, which is refering to these classes as supertypes.

New classes could also uses the existing 2 class supertypes, for the built-in types; after all, they're already there. There seems to be no value in having also versions of these in the 1 class source form.

DocumentAnnotation

This is a special case - being the only type which is both a built-in type as well as a type which the user can extend. The solution here is probably to generate JCasGen cover classes for this type which are in the 2-class format.