uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: Generics in 2.8.0 getAllIndexedFS
Date Tue, 07 Jul 2015 20:30:10 GMT
A good reference: 


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>
> 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

View raw message