[
https://issues.apache.org/jira/browse/UIMA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15603068#comment-15603068
]
Marshall Schor commented on UIMA-4687:
--------------------------------------
The only reason would be aesthetics in usage, and balancing that against
wanting to communicate the fact that these are static constants.
I don't feel strongly, but what small feeling I have made me switch the form of
the name (I had originally typed:
{code}
public final static String _TYPE_NAME = "pack.age.name.Sentence"; // new
static final string constants added
public final static String _FEAT_NAME_xxxx = "xxxx"; // for features
// allows
@TypeCapability( // use example
inputTypes = {
@Type(Sentence._TYPE_NAME ),
@Type(value=Token.class, features={Token._FEAT_NAME_pos ,
Token._FEAT_NAME_lemma})})
{code}
and I thought it looked too ugly, and thinking that looks were more important
than purity / need to signal static constant.
> 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)
