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