uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: [VOTE] uimaj 3.0.3 rc2
Date Fri, 02 Aug 2019 18:19:16 GMT
Hi,

I did a small test setup - made a main routine in a test class, and ran it. 

It too shows all the issues. Here's the routine - it only uses Java basic
things, no UIMA.

  public static void main(String[] args) {
    ArrayList<Number> tokens = new ArrayList<>(1);
    tokens.add(3);  // add one element to the list
      
    tokens.set(0,  4);  //ok - no compile or runtime error
    ArrayList unknown = tokens;  // compile time warning
    unknown.set(0, 5);           // compile time warning, runtime ok
   
    ArrayList<? extends Number> generalize = (ArrayList<? extends Number>)
tokens;
   
    // generalize.set(0, 6);  // compile time error

  }

In fact, there's no cast I could figure out to make "generalize.set" work at
all, except by changing its definition to use ArrayList (bare with no generic
argument):
  
    ArrayList generalize = (ArrayList<? extends Number>) tokens; //compiles with
warnings,
    generalize.set(0, 7);  // works at runtime

The book "Effective Java" by Josha Bloch says "Do not use bounded wildcard types
as return types".  This is because it "forces users to use wildcard types in
client code", and

There is some discussion here:
http://www.angelikalanger.com/GenericsFAQ/FAQSections/ProgrammingIdioms.html#FAQ303

I'm pretty sure it would cause a lot of issues if this method were to "return" a
bounded wild card.

-Marshall

On 8/1/2019 5:24 PM, Hai-son X Nguyen wrote:
> Sorry, let me rephrase, the 3.0.0 - 3.0.2 version exposed potential bugs. As our code
is littered with FSArrays I wanted to fix the warnings to prevent future calamities like below:
>
> Sentence sentence = ...;
> FSArray<Token> tokens = sentence.getTokens();
>
> tokens.set(1, sentence); // <- compile error Case #1
>
> FSArray unknown = tokens; // <- warning
> unknown.set(1, sentence); // <- nothing warnings, compiles - runtime error Case #2
>
> FSArray<? extends FeatureStructure> generalize = (FSArray<? extends FeatureStructure>)
tokens;
>
> generalize.set(1, sentence); // <- compile error Case #3
>
> It is different for the Iterator which is not a modifiable interface, so one always thinks
it should be allowed! Took me a while to research and remember why Java complains about that
casting equivalent to Case #2.
>
> From the apache versioning guidelines, it looks like binary compatibility is there but
patch version requires both perfect binary and source compatibility
>
> We could adjust the update to return FSArray<? extends FeatureStructure> instead
to meet the source compatibility too.
>
> Hai-Son
>
> On 8/1/19, 12:46 PM, "Richard Eckart de Castilho" <rec@apache.org> wrote:
>
>     Caution: This email came from outside Kaiser Permanente. Do not open attachments
or click on links if you do not recognize the sender.
>
>     ______________________________________________________________________
>     On 1. Aug 2019, at 21:41, Hai-son X Nguyen <Hai-Son.Nguyen@kp.org> wrote:
>     >
>     > for (FeatureStructure attrFS : (Iterable<? extends FeatureStructure>)
aElement.getAttributes()) {
>     > ...
>     > }
>     >
>     > I don't think it is a runtime error but a bug on the DKPro side, the FSArray
contract is FSArray<T extends FeatureStructure> implements Iterable<T>
>
>     I also don't think it'd be a runtime error, but it is also not a bug in DKPro Core.
>
>     UIMA 3.0.2 (before your change) generated a getter which returned only an FSArray
*without* a generic type specification. For that case, the compiler did not create an error
for the type cast that I used.
>
>     But with UIMA 3.0.3, the getter is now generated *with* a generic type specification
which makes the type cast invalid. Your proposed change to the type-cast might fix this, but
the issue is that with 3.0.2 there was no problem and with 3.0.3 there is.
>
>     Anyway, I'm happy to be able to entirely remove the type-cast with UIMA 3.0.3 - thank
you very much for the contribution!
>
>     IMHO it's just a matter of choosing the right version number and properly documenting
this quirk.
>
>     -- Richard
>
>
> NOTICE TO RECIPIENT:  If you are not the intended recipient of this e-mail, you are prohibited
from sharing, copying, or otherwise using or disclosing its contents.  If you have received
this e-mail in error, please notify the sender immediately by reply e-mail and permanently
delete this e-mail and any attachments without reading, forwarding or saving them.  Thank
you.

Mime
View raw message