Use Advanced Search to search the entire archive.
Re: Email proposal to the core-libs-dev@openjdk.java.net
- From: Otávio Gonçalves de Santana <
>
- To:
- Subject: Re: Email proposal to the
- Date: Sun, 19 Oct 2014 20:42:59 -0200
Ok Leonardo, waiting the issue to talk about remove these methods.
On Oct 19, 2014 7:34 PM, "Leonardo Lima"
<
>
wrote:
>
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
>
>
>
>