Page History

...

• JCasGen could be "automatic" for merged type systems, and merged instances of JCasGen'd user classes?
  • Users still would need a generated version for their code to compile against.
• Pear definitions for JCas cover classes could be merged?
• Could generate one kind of Java cover class for all types. (lazy, load on demand
  • eliminate / reduce use of TypeImpl in runtime.
  • generate for all merged types (except custom built ins)
    • (as opposed to current impl, where no JCas cover class is generated if it doesn't exist - the "standard" one is used instead)
• use class loader technology to support multiple type systems.systems 
  • Having same-named types, sharing the JCas cover types for those, but (after merging) having different sets of features.
  • This would only be used for UIMA (merged) Types
  • only for class definitions that have same name but are differenthave different feature sets.
  • Current design uses the same JCas cover class for differing type systems (e.g., ones that have a different # of features for a type).  In this case, the JCas cover type only is being used to set/read slots it knows about; other facilities might be used to read/set additional slots.

Feature Structure == an instance of its Java Cover class

...