Page History

...

• To get around "reflection" slowness: 
  • Support set/get by int <- class <- feature-name-string
  • Support set/get (bulk) ? <ordering among fields significant?>
  • possibly use something like ReflectASM which is like Java reflection but has a byte-code generator and is much faster (but probably not as fast as custom support code compiled into the Java Cover class).

Simple Type adapters

Data Model (Types and Features) adapters

One of the values for UIMA is the facilitating interoperability among components. One difficulty in this is that different components may have somewhat different data models, with different names for similar things.

This topic looks at making this betterAt startup-time, the Java classes for types could be generated from the "merge" of type information in all components (this merge is done in current UIMA, and is intended to let annotators "extend" each other's type model with additional features). In addition to this, more could be done to allow for simple adaptation - such as one annotator calling a feature "tokenLemma", and another one calling the same feature "lemma".  These would translate into having multiple getters and setters for the same underlying field in the Java class.   More complex adapters could be envisioned over time, including some custom things (that could be Java "wrappers" that give additional views of the same underlying data - thus avoiding the problem of duplicate data for the same idea).  These could be incented into a web-based eco-system intended to encourage reuse.

User customization of Java cover classes, and PEAR classpath isolation issues

...