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

Marshall Schor commented on UIMA-4687:
--------------------------------------

For UIMA V3 JCas, we could add some static final constants for the type and 
feature names:
{code}
public final static String _TypeName = "pack.age.name.Sentence";  // new static 
final string constants added 
public final static String _FeatName_xxxx = "xxxx";    // for features
// allows
@TypeCapability(          // use example
  inputTypes = { 
    @Type(Sentence._TypeName ),
    @Type(value=Token.class, features={Token._FeatName_pos , 
Token._FeatName_lemma})})
{code}


{code}

@Type(Sentence._TYPE_NAME)
{code}

Would this satisfy the needs you envisioned here and in UIMA-2147?

> 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)

Reply via email to