THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Explore the consequence of allowing the various implementations of Java List, Set, and Map to be 1st class UIMA types.
- Could even have the same package name, so their JCas cover classes follow naming conventions
- Would need serialization / deserialization code for our various forms
- Would (optionally) need C++ impl support. Alternative - the new types would be excluded from being passed.
Issues with "equals" and "hashcode" and "compare"
The Java implementations of these are called. We don't (currently) have a method of defining these for UIMA Types.
- An extension to the type system specification could define these in terms of UIMA Types used as keys.
- How to handle type merging - might add new features that could be spec'd to be part of these functions.
- For hashcode / equals - is sufficient to say feature is included or not
- for compare - there's also an "ordering" consideration - what feature would be compared first. This seems to be unsolvable given the constraints of independently developed components / type system defs. Perhaps for this we might "require" a hand-merged type system spec. and throw an error otherwise.
- How to handle type merging - might add new features that could be spec'd to be part of these functions.