I perhaps overstated the problem. Here's the specifics: if the maximal-type system for type T has features f1, f2, f3, f4, f5, and the JCas class defines all these features, then the load of that JCas class will bind those.
A subsequent switch to a type system with f1, f2, will work. But a subsequent switch to a type system with f1, f3 won't work (because the offset for f3 is set to, say "3", and the length of the feature slots allocated is only 2. To work around these, the application needs to use class loader isolation to force reloading of the JCas classes. (Or, as mentioned earlier, we could have an API to recalculate the offsets, but that could really break things if instances of that JCas class exist (perhaps running in other threads) expecting the other definitions. So I think any client code doing type system switching, and using JCas classes where the features are changing, needs to be aware and handle this (currently). A fix along the lines suggested where the JCas classes augment the type system, could help, but it would still be exposed to edge cases like this: TypeSystem 1 defines type T with f1; JCas augments this with f100. Later a typesystem is loaded which defines types f1, f2, and f100 (in that order). The JCas for T has bound f100 to (say) slot #2, which is where this type system has stuck "f2" - so it has the wrong binding for f100. -Marshall On 1/5/2018 4:25 PM, Richard Eckart de Castilho wrote: > On 05.01.2018, at 21:29, Marshall Schor <m...@schor.com> wrote: >> So, the only work-around I see at the moment is to use class loader >> isolation, >> reloading the JCas classes each time. > Is this something that client code would have to be aware of / to trigger? > > Cheers, > > -- Richard
