Based on Web Annot's use case, I'm thinking thorough alternatives. The issue is a sequence related one, with type systems changing:
1) a type system is created, defining type T, with no features 2) a CAS is produced with that type system, causing JCas classes to be looked-up and loaded At that time, the JCas class is set up with feature offset constants, corresponding to how the features are laid out in the type system. Type T has 0 features, but the JCas type for T might define some. This is allowed, but the feature offsets in the JCas class are set to -1, which will cause a runtime exception if the feature is used (e.g., someone does myJCasType.getMyFeature() call). So far - all OK (provided the non-existent features are not accessed, of course). 3) a different type system is created, defining type T with feature f1 4) a CAS is produced with that type system. Currently this throws an error when the JCas classes are checked for conformance with the type system. A mechanism in the JCas already allows the JCas classes to be "updated" for feature changes. However, once the JCas class is loaded with a valid type system, no updating is allowed (for reasons see below). The consequence of this is that a user wanting to use one set of JCas classes with multiple different type systems must use the maximal-feature version of the type systems (which could be created using a type system merge operation, for example), as the *first* type system that causes the JCas classes to be loaded. We could modify the JCas setup to allow updating an already loaded/initialized JCas class for a new type system with different features present. But it seems that this has some difficulties; it would only be a valid transformation if no instances of the JCas class exist. There's currently no way to tell if this is true. In the general case, the JCas classes could be being used for multiple independent pipelines, running in multiple threads; so even if one CAS was "reset", others might not be; and furthermore, POJO code could be holding on to some JCas instances. One way to support this would be to have the user code tell the UIMA framework that no reachable instances of JCas classes exist; the user would be responsible for guaranteeing this. The other choice would be to not support this (because of the inherent dangers) and instead require users having multiple type systems with JCas classes specifying features only in some versions of those type systems, first load the JCas classes with the feature-maximal versions of the types. I think I favor the 2nd approach, as it is much safer. What do others think we should do? -Marshall
