Use Advanced Search to search the entire archive.
Re: Email proposal to the core-libs-dev@openjdk.java.net
- From: Werner Keil <
>
- To:
- Subject: Re: Email proposal to the
- Date: Mon, 20 Oct 2014 00:28:38 +0200
If Otavio feels his proposal does not matter any more we'll close it with
"Won't fix";-)
At some point, maybe when we p;-)resent an EDR, or at least by the time EC
first gets to vote, it would be good if somebody at Oracle beyond Don had a
look at it.
I tested Jean-Marie's example code against 2 versions of JScience and it
works well, including runtime exception.
I can't say, if a convenience method like that on Quantity or even
Measurement (they are both equally typesafe, and Quantity would
inherit/override it accordingly) works, but it is worth a thougt.
A problem from SE 8u20 on that we should keep an eye on is however a
problem between those wildcard operations and asType() which is dedicated
to those especially, so if they together break the code it seems quite
odd;-/
It occurs under SE 8u20, when a method takes a Unit<?> argument and the
result of Unit.multiply(Unit<?).asType() is passed to that method.
E.g. len.multiply(len).asType(Area.class)
Which is perfectly legitimate, but compilation already fails with:
incompatible types: inference variable T has incompatible bounds
equality constraints: javax.measure.quantity.Area
upper bounds: javax.measure.Quantity<capture#1 of
?>,javax.measure.Quantity<T>
Since it refers to the T in asType() and <?> from multiply (or the second
wildcard?) there must be a relation.
As Otavio's proposal was dismissed I won't even bother to test, how it
would work if multiply() had his proposed signature, but see UCUM system
where a similar bug occurred dozens of times in every system, passing the
result of asType() into a non wildcard method currently works.
If I get online in Germany I'll push ReflectionDemo with lines that would
break compile and those that don't.
Then you can play with it and see, what remedies exist.
Potentially ask JDK team a question around that, but if both Otavio
withdrew his proposal and at least 2 Spec Leads would veto it, I agree with
the ticket to be closed/denied.
Let's hope other JIRA tickets are easier, so we don't risk a Renewal
Ballot;-)
Regards,
Werner
Am 19.10.2014 23:34 schrieb "Leonardo Lima"
<
>:
>
I think that a nice round up is needed again :)
>
>
We all but Werner would NOT like the "new signature", we (Leo, Otávio,
>
Martin and Jean-Marie) understood it breaks some rules and logic. Still,
>
that doesn't solve some other problems and raises other questions like
>
"should we remove the operation or not", but *that's for another mail
>
thread and JIRA issue*. JIRA #62 (and that mail thread) is about changing
>
the signature method.
>
>
I really don't know if Werner is pushing for or against the new signature
>
(the new signature is the one proposed by Otávio).
>
>
Werner, a simple yes and no question: do you want the new signature?
>
>
>
On Sun, Oct 19, 2014 at 6:51 PM, Werner Keil
>
<
>
>
wrote:
>
>
>
>
> Am 19.10.2014 22:22 schrieb "Martin Desruisseaux" <
>
>
>:
>
> >
>
> > Bellow is my email proposal for the
>
> >
>
> list (I may edit again tomorrow). Is there any objection or change
>
> proposal?
>
> >
>
> > 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.
>
>
>
> > ________________________________
>
> >
>
> > Subject: Interpretation of parameterized type usage in a JSR
>
> >
>
> > Hello all
>
> >
>
> > My apologize for resorting to this mailing list for a question about an
>
> external API. I'm doing that, with agreement from other members of the JSR
>
> group, for a JSR which could possibly be proposed for inclusion in the JDK
>
> in some future version. I'm seeking confirmation about whether the
>
> following rule shall suffers no exception. In a nutshell (more detailed
>
> explanation below), given the following method signature where X, Y and Z
>
> are interfaces:
>
> >>
>
> >> X<Y> foo();
>
> >
>
> > I claim that it would be unacceptable to have the foo() method
>
> implementation actually returning instances of X<Z> through parameterized
>
> type erasure (ignoring cases like Collections.emptyFoo() where object
>
> properties do not depend on the parameter type). I claim that no "developer
>
> convenience" consideration can justify such breaking of Java parameter type
>
> safety. Some other peoples have the point of view that the developer should
>
> know what he is doing.
>
> >
>
> > Details
>
> >
>
> > In this discussion I use the standard Comparable<?> interface and its
>
> Short and Integer implementations for familiarity, but the actual JSR
>
> objects are different. Consider the following method:
>
> >>
>
> >> <X,Y> Comparable<?> multiply(Comparable<X> x, Comparable<Y> y);
>
> >
>
> > Let assume that the type of the return value is not necessarily the
>
> type, or a subtype, or a super-type of any of the arguments. It may be for
>
> example because the multiply method applies the Java rules of Binary
>
> Numeric Promotion (JLS §5.6.2). Consequently, the return type use the <?>
>
> wildcard since we can not express the actual return type as a function of X
>
> and Y with the parameterized type syntax. This force the users to cast as
>
> in the following example:
>
> >>
>
> >> Short x = 3;
>
> >> Short y = 4;
>
> >> Integer r = (Integer) multiply(x, y);
>
> >
>
> > For reasons out of scope of this email, some peoples want to use only
>
> the base interface:
>
> >>
>
> >> Comparable<Short> x = (short) 3;
>
> >> Comparable<Short> y = (short) 4;
>
> >> Comparable<Integer> r = (Comparable<Integer>) multiply(x, y); //
>
> Unsafe cast
>
> >
>
> > Some peoples in our JSR group feel very strongly against the <?>
>
> wildcard in return value. They consider it as a sign of bad design (note
>
> that I disagree - for me in this particular situation, it means "can not be
>
> expressed by the current Java parameterized type syntax". A JDK example of
>
> such case is Class.getEnclosingClass()). Some peoples are pushing for the
>
> following method declaration:
>
> >>
>
> >> <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?
>
> There's no need to cast required, so except the multiply() line the
>
> others seem unrelated and make no real sense.
>
>
>
> > The cast and the warning disappeared, which was the effect desired by
>
> the promoters. But that method signature also let users write:
>
> >>
>
> >> Comparable<Byte> r1 = multiply(x, y); // Wrong!
>
> >> Comparable<Float> r2 = multiply(x, y); // Wrong!
>
> >> Comparable<String> r3 = multiply(x, y); // Wrong!
>
> >> etc...
>
> >
>
> > Above code compile without warnings and can run, but will fail randomly
>
> at some later point when the assigned variables will be used. This is
>
> understood, but partisans of the later method signature said that
>
> developers should know what they are doing. My point of view is that no
>
> argument can justify to break the Java parameterized type safety that way.
>
> >
>
> > Alternative exists (e.g. not using parameterized types at all, do
>
> something similar to Class.cast(Object), etc.), but I would like to have a
>
> confirmation - or a correction if I'm wrong - of the following:
>
> >
>
> > Public parameterized method which are impossible to implement without
>
> unprovable "unsafe cast" warnings, and which are known to break
>
> parameterized type safety, are unacceptable.
>
> > There is nothing wrong in using the <?> wildcard in a return value if
>
> the actual type can not be expressed by the Java parameterized type syntax.
>
> >
>
> >
>
> > Regards,
>
> >
>
> > Martin
>
> >
>
>
>
> 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 (@Otavio, what have you done there so far if anything?;-)
>
>
>
> Regards,
>
> Werner
>
>
>
>