A good reference: http://www.angelikalanger.com/GenericsFAQ/FAQSections/ProgrammingIdioms.html#FAQ303
-Marshall On 7/7/2015 3:37 PM, Marshall Schor wrote: > 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 > >
