Currently there are three static methods on JCasImpl that are called from JCasGen-erated cover classes. I'd like to do something about this because it means we haven't fully separated the JCas interface and implementation. For example I could (theoretically, someday) call new MyJCasType(jcas) where jcas is NOT an instance of JCasImpl but some other implementation of the JCas interface. However, MyJCasType would still be invoking static methods on JCasImpl. That can't be right.
I think there's a reasonably easy solution to this. For background, the three static mehods that are called from cover classes are: * getNextIndex: This is the most important one. Whenever a cover class is loaded, it calls this to obtain an integer "index" that uniquely identifies that type. This must be called from a static context (there's no instance of JCas available at load time). * getFeatOkTst: This is actually not yet implemented, it just always returns true. The idea was to enable, by some static configuration, the ability to gain performance by disabling some runtime checking that catches incompatibilities between the JCAS cover class and the CAS type system. It's important that this is static, because it's assigned to static final fields in the JCas cover classes, enabling the checks to be "compiled out" by the JIT. * throwFeatMissing: This is a convenience method, and doesn't necessarily need to be static. I recommend we make this non-static and add it to the JCas interface (but marked "internal use"). To deal with the first two I propose we create a new class, which I'm calling JCasRegistry. JCasRegistry would include the methods getNextIndex and getFeatOkTst. It would also include the method getCurrentIndex(), to be called from JCasImpl. It might also need a method like getJCasTypeForIndex(int), also to be called from JCasImpl, but that's a detail that can be worked out during implementation. JCasRegistry would be in the org.apache.uima.jcas package, so it would be considered essentially part of the JCas interface definition, i.e. it's not specific to JCasImpl -- any future JCas implementation would (or could) make use of it. We could even attach this directly to the JCas interface itself via a field: static final JCasRegistry REGISTRY = new JCasRegistry(); If we did this then the methods on JCasRegistry would be non-static and cover classes would call JCas.REGISTRY.getNextIndex(). If we didn't they would be static, and cover classes would call JCasRegistry.getNextIndex(). I think it works either way. IMO a design like this would be preferrable to the current situation where we have references directly to JCasImpl. -Adam
