[
https://issues.apache.org/jira/browse/UIMA-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16161898#comment-16161898
]
Marshall Schor commented on UIMA-5554:
--------------------------------------
The intent is to have JCas not be much more restricted in v3. The only thing
new is the requirement to commit the type system (which loads the JCas classes
for those types), before referencing the types in a manner which would cause
them to be loaded *and initialized* .
Here's a simple example.
Class Foo defines feature foo1 and foo2, both "integer". UIMA type Foo defines
feature foo1, foo2, and foo3. (after merging, say).
This is perfectly permissible (that the JCas class only defines a subset of the
merged type definition).
When the Class Foo is *initialized*, it has a statement for each field to set
up a bridge to the actual type system. These statements look like:{code}
public final static int _FI_foo1 =
TypeSystemImpl.getAdjustedFeatureOffset("foo1");{code}
At class-initialization-time, _FI_foo1 could get set to 0, 1, or 2, depending
on the ordering of these features in the committed type system.
You are right to say the compiling of the JCas classes *predate* the loading.
The JCas classes are compiled without any "bindings" of where the feature slots
go - they just have these "instructions" implemented as static initializers,
which, when run with the current loaded type system, do the right thing.
The way this normally works, is that this initialization happens when the type
system is committed (the type system "commit" method is called). When that
happens, the type system commit method commits the type system, and then sets
up a threadLocal value identifying which type system (of perhaps many) is being
committed, and then calls the code to find and load any JCas classes for the
types in this type system (there many be many, or few, or none - well, there's
always the built-in ones...).
Does that help?
> Strange exception when trying to get JCas FS class through reflection
> ---------------------------------------------------------------------
>
> Key: UIMA-5554
> URL: https://issues.apache.org/jira/browse/UIMA-5554
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
> Affects Versions: 3.0.0SDK-beta
> Reporter: Richard Eckart de Castilho
>
> I am trying to get a class object for a JCas FS type using reflection:
> {noformat}
> Class.forName(typeName);
> {noformat}
> However, it produces this strange error.
> {noformat}
> java.lang.ExceptionInInitializerError
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> ...
> Caused by: org.apache.uima.cas.CASRuntimeException: A JCas class field "sofa"
> is being initialized by non-framework (user) code before Type System Commit
> for a type system with a corresponding type. Either change the user load code
> to not do initialize, or to defer it until after the type system commit.
> at
> org.apache.uima.cas.impl.TypeSystemImpl.getAdjustedFeatureOffset(TypeSystemImpl.java:2575)
> at
> org.apache.uima.jcas.cas.AnnotationBase.<clinit>(AnnotationBase.java:71)
> ... 27 more
> {noformat}
> Is it considered harmful to try getting a class object for a JCas FS class?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
