Here I want to add a comment, reflecting the experiences with OSGi. The idea with the static final method to create a unique index in the JVM is very good. In OSGi however, it creates problems. The nature of OSGi is loading bundles in different class loaders, which for themselves define some relations to each other (hierarchical). Now, if we have the same type system as JCas classes loaded by different class loaders, each one gets a new ID, because the class is loaded more than once. This behavior can be changed with a global registry class as proposed here. So it is a +1 from my point of view. Although, there are more issues, I think it is an important step.
On 1/12/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
Adam Lally wrote: > Pushed send a little too quick... I also had another point to make. > > Currently getNextIndex() does something strange - it queries the > current Java stack trace to figure out which cover class called it, so > that it knows which index is assigned to which class. This was added > after-the-fact so as to record this information without having to > change the interface definition. > > A cleaner design might be to change this to > JCasRegistry.register(Class). This would involve some additional work > in my migration script to make these changes to existing cover > classes, but it shouldn't be that difficult. > > -Adam > > +1 to both of these notes. I would prefer the approach where the JCasGen-erated things directly call the static methods, rather than going through a static final ref in the JCas interface, because it's simpler, and may have some performance implications for the JIT optimizer on some JVMs. Nice work, Adam :-) -Marshall
