This page collects ideas for loading JCas classes including customization(s).
Each UIMA type have feature structure instances represented by instances of a corresponding (usually generated) Java class.
- The instances of these classes are the feature structure; the fields store the feature values.
- 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[].
- Uima types which have natural corresponding Java equivalents have feature values stored using the natural corresponding Java types
- Most UIMA built-in types have standard defined Java class definitions.
Design considerations
- Built-in types support - would be nice if these were not needlessly replicated
- 1 JVM, multiple type systems - 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.
- 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.
What's in a JCas cover class?
There are two classes for each type.
- x.y.z.Foo - each instance represents one Feature Structure; in v3 these can be GC'd
- x.y.z.Foo_Type - there is one instance per CAS (arbitrary view)
x.y.z.Foo
Has
- a field for each feature
- a reference to the _Type instance
- only for backwards compatibility for low-level access model
- One instance per type system
- has ref to TypeImpl?
- a reference to the CAS View (needed for backwards compatibility, and to support addToIndexes for the right view)
- a ref to a type-system-wide Bitset for index corruption testing
- Constructors
- new Foo(Cas)
- Methods
- getter / setter for all fields
- The setter methods may include index corruption checking code.
- May be code which tests at runtime on each set, whether or not this
- The setter methods may include index corruption checking code.
- indexed getter/setter for fields defined as arrays
- (via inheritance)
- a collection of get/set methods, one per boolean/byte/short.../double/String/TOP/JavaObject and arrays of these, kinds of values.
- The methods take an extra "offset" value, obtained from the Feature.
- Used for backwards compatibility with non-JCas styles, and for serialization and other "generic" operations
- a collection of get/set methods, one per boolean/byte/short.../double/String/TOP/JavaObject and arrays of these, kinds of values.
- getter / setter for all fields
x.y.z.Foo_Type
has
- a ref to the TypeImpl
- a ref to the CAS (an arbitrary view, sometimes updated in v2), used for low level access patterns