You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Marshall Schor (JIRA)" <de...@uima.apache.org> on 2015/10/28 22:35:27 UTC
[jira] [Updated] (UIMA-4663) UV3 Represent Feature Structures as
Java Objects
[ https://issues.apache.org/jira/browse/UIMA-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marshall Schor updated UIMA-4663:
---------------------------------
Description:
Switch the storage model for Feature Structures to align with Java's Object Model, while preserving backwards compatibility.
This allows garbage collection of Feature Structures.
There is likely a performance benefit by having the data in one place only, with no conversions needed between the Java world and the data-on-the int-heap world of V2.
JCasGen capability (optional) will create Java fields representing the Feature values; getters will become simple get operations. Setters are more complex due to the need to support things like index corruption checking and journaling (when using Delta Cas operations).
Types without JCasGen'd classes will use generic Java class representation and store their features in a couple of local collections.
Mixing of these two approaches is also possible; e.g., the built-in type Annotation defines begin / end fields, which are represented as Java fields. Additional features may be represented by subtypes having no JCasGen'd class definition, and those fields would be saved in the generic local collections.
The goal is to support fast/efficient access both with and without JCas-gen'd classes.
was:
Switch the storage model for Feature Structures to align with Java's Object Model, while preserving backwards compatibility.
This allows garbage collection of Feature Structures.
There is likely a performance benefit by having the data in one place only, with no conversions needed between the Java world and the data-on-the int-heap world of V2.
> UV3 Represent Feature Structures as Java Objects
> ------------------------------------------------
>
> Key: UIMA-4663
> URL: https://issues.apache.org/jira/browse/UIMA-4663
> Project: UIMA
> Issue Type: Story
> Components: Core Java Framework
> Reporter: Marshall Schor
>
> Switch the storage model for Feature Structures to align with Java's Object Model, while preserving backwards compatibility.
> This allows garbage collection of Feature Structures.
> There is likely a performance benefit by having the data in one place only, with no conversions needed between the Java world and the data-on-the int-heap world of V2.
> JCasGen capability (optional) will create Java fields representing the Feature values; getters will become simple get operations. Setters are more complex due to the need to support things like index corruption checking and journaling (when using Delta Cas operations).
> Types without JCasGen'd classes will use generic Java class representation and store their features in a couple of local collections.
> Mixing of these two approaches is also possible; e.g., the built-in type Annotation defines begin / end fields, which are represented as Java fields. Additional features may be represented by subtypes having no JCasGen'd class definition, and those fields would be saved in the generic local collections.
> The goal is to support fast/efficient access both with and without JCas-gen'd classes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)