This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • JCas design, v3, separate data and cover classes
Skip to end of metadata
Go to start of metadata

This collects design thoughts for an approach for JCas v3, which has the following aspects:

  • Separate the JCas aspect which gives java-like reference to data, from the storage of the data
  • Have a general purpose class instance that stores the data for one FeatureStructure
    • has two arrays
      • of ints - for storing primitive data
      • of references to Java Objects for storing everything else
      • arrays might be variable length if useful, otherwise fixed length (set upon creation of instance).
    • has ref to TypeImpl instance (and from that, to supertypes, etc.
    • has ref to JCas cover class instance (if it exists, or a super type, if it exists)
    • has "id" for backwards compatibility (dense)
  • Have optional JCas classes for Java friendly by name reference to the UIMA type and features.
    • similar to how it is now


  • No labels