Use Advanced Search to search the entire archive.
Re: Email proposal to the core-libs-dev@openjdk.java.net
- From: Martin Desruisseaux <
>
- To:
- Subject: Re: Email proposal to the
- Date: Mon, 20 Oct 2014 11:50:04 +0900
- Organization: Geomatys
Le 20/10/14 05:51, Werner Keil a écrit :
>
>
> Note the following risk: if we get an answer, I'm 100% sure that the
>
answer will be that such break of parameterized type safety in the
>
core JDK is a big no-no, with no excuse tolerated. Some peoples may be
>
surprised that a JSR group considered such idea seriously enough for a
>
debate, to the point of becoming reluctant to include anything coming
>
from such group in the JDK.
>
>
That is out of discussion, since we propose a standalone JSR.
>
If we succeed going 1.0 maybe some day a platform part could find it
>
interesting, but I see that more likely on ME, than SE.
>
Is it a suggestion for removing the "/for a JSR which could possibly be
proposed for inclusion in the JDK in some future version/" sentence? I'm
okay with that if you confirm me that this is your suggestion.
>
>> <X,Y,R> Comparable<R> multiply(Comparable<X> x, Comparable<Y> y);
>
>
>
> In the above method signature X, Y and R appear independents - our
>
relationship between (X,Y) and R is not expressed. Of course this
>
method is impossible to implement without "unsafe cast" warnings, and
>
those casts can not be proved to be safe. But that method signature
>
allows users to write:
>
>>
>
>> Comparable<Short> x = (short) 3;
>
>> Comparable<Short> y = (short) 4;
>
>> Comparable<Integer> r = multiply(x, y);
>
>
What are you trying to explain here, the <?> version, or the proposed
>
alternative?
>
The last line illustrates application of the UNITSOFMEASUREMENT-62
alternative: parameterizing the return type with "R".
>
There's no need to cast required, so except the multiply() line the
>
others seem unrelated and make no real sense.
>
Okay, I think I got you point: you are perturbed by the (short) casts,
which are there only for auto-boxing and are indeed unrelated to our
discussion. I will replace the (short) casts by Short.valueOf(...) for
making that clear.
>
It could be worth adding, some JSR members who considered the wildcard
>
a bad or outdated practice already work with the JDK team, at least
>
via AdoptOpenJDK
>
This is not a technical argument.
Martin