uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Eckart de Castilho (JIRA)" <...@uima.apache.org>
Subject [jira] [Commented] (UIMA-4687) UV3 improve JCas feature id use for index corruption checking and journaling
Date Mon, 09 Nov 2015 15:30:11 GMT

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

Richard Eckart de Castilho commented on UIMA-4687:
--------------------------------------------------

Cf. https://issues.apache.org/jira/browse/UIMA-2147?focusedCommentId=13605332&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13605332

When I want to use the *names* of types and features, e.g. in Java annotations in uimaFIT,
I cannot use anything that requires calling a method. Having static fields representing the
names in JCas classes (similar as having them in the CAS interface for the builtin types)
would be a nice thing.

> UV3 improve JCas feature id use for index corruption checking and journaling
> ----------------------------------------------------------------------------
>
>                 Key: UIMA-4687
>                 URL: https://issues.apache.org/jira/browse/UIMA-4687
>             Project: UIMA
>          Issue Type: Sub-task
>          Components: Core Java Framework
>            Reporter: Marshall Schor
>            Assignee: Marshall Schor
>            Priority: Minor
>             Fix For: 3.0.0SDKexp
>
>
> When setting (changing) values for features, sometimes index corruption checking needs
to be done, and sometimes changes need to be journaled.  Both of these need to identify the
feature involved.  This operation should be fast and memory-cache-friendly (e.g. not involve
following a long chain of dereferencings).  
> Add static final fields that represent features used by a particular JCas class, which
have names derived from the short-feature-name, and won't collide with other names, and set
these using the same JCasRegistry mechanism to unique values within a class loader.  This
allows the same JCas cover classes to be used with different type systems.  
> Change the corruption testing logic to use BitSets and have a version which uses these
indexes as well as one which uses the FeatureImpl featureCode.  Keep one extra table mapping
these codes to FeatureImpls, per type system. 



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

Mime
View raw message