uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (JIRA)" <...@uima.apache.org>
Subject [jira] [Commented] (UIMA-4663) UV3 Represent Feature Structures as Java Objects
Date Mon, 02 Nov 2015 14:15:27 GMT

    [ https://issues.apache.org/jira/browse/UIMA-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14985261#comment-14985261
] 

Marshall Schor commented on UIMA-4663:
--------------------------------------

I think you have a good idea there, Richard; thanks!

I'll wait a day or two to see if others have opinions on this naming, and otherwise plan to
change to id().

> 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.
> Assign for each new Feature Structure created in a CAS, an incrementing ID, starting
at 1. This id may be retrieved using a new FeatureStructure method get_id().  
> Name new internal fields and methods to start with an underscore to avoid collision with
user-defined feature names, which cannot start with an underscore.
> Update CASImpl to remove heaps, remove (unused) FSCache mechanism.  Update JCasImpl to
remove JCasHashMap, always have built-ins as JCas cover objects (load them even if JCas isn't
being used).  Convert Generators to use Java 8 method handles.  Add method handle bridge from
non-JCas feature access to JCas object access (where JCas objects exist), for getters and
setters.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message