Burn reports a source incompatibility with the 2.8.0 signature for the getAllIndexedFS. This is a somewhat complex issue. Here's what I've found so far:
1) We have 3 sets of versions of getAllIndexedFS - one in the plain CAS index repo, one in the JCas version of the index repo, and one directly in the JCas itself. The signatures are not consistent. 2) https://issues.apache.org/jira/browse/UIMA-4299 strongly suggests not returning values of <? extends XXX>. We opted in the plain CAS version to use <T extends FeatureStructure> FSIterator<T> getAllIndexedFS(...) and in the JCas index version: FSIterator<FeatureStructure> getAllIndexedFS(...), and in the JCas itself: <T extends TOP> FSIterator<T> getAllIndexedFS(Class<T> clazz) 3) At first I thought that it was quite possible that the getAllIndexedFS call will produce an iterator which returns a mixture of subtypes of the specified class, or instances of FeatureStructure, which are not a subtype of the specified class, and would produce a ClassCastException when assigned to a variable of the iterator type. I thought that FeatureStructure will be produced if there is no JCas cover class, but I think this is incorrect. There are generators for each type that generate the corresponding Java class. As part of the JCas creation, the method instantiateJCas_Types is called and will replace the generators with JCas versions. If no JCas cover class can be found for a particular type, the generator is still replaced with one for the first JCas cover type found in the supertype chain. Since TOP is a built-in defined JCas type, even if no other types have JCas cover types, TOP will. 4) Current user code often has some JCas cover class as the top-most class of some set of Java cover objects being returned. These are currently failing for some forms of getAllIndexedFS calls - the ones returning FSIterator<FeatureStructure> These should be changed (back) to returning either <T Extends TOP> or just TOP. 5) I'd like to use the <T extends TOP> form, but would like other Java experts to weigh in to see if that would cause issues... To be precise, I'd like the signature to look like: <T extends TOP> FSIterator<T> getAllIndexedFS(...) for those calls that don't specify the Java class in the argument. The pros for this is that the coder can specify a subtype of TOP if they know that will be returned. The con for this is that the coder could make a mistake, and a runtime class-cast exception could happen, if the item returned was not a subtype. Other learned opinions politely solicited :-) . -Marshall
