Skip to main content

Re: Email proposal to the core-libs-dev@openjdk.java.net

  • From: Leonardo Lima < >
  • To: " " < >
  • Subject: Re: Email proposal to the
  • Date: Sun, 19 Oct 2014 19:33:23 -0200

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
>


Email proposal to the

Martin Desruisseaux 10/19/2014

Re: Email proposal to the

Otávio Gonçalves de Santana 10/19/2014

Re: Email proposal to the

Martin Desruisseaux 10/20/2014

Re: Email proposal to the

Werner Keil 10/19/2014

Re: Email proposal to the

Leonardo Lima 10/19/2014

Re: Email proposal to the

Werner Keil 10/19/2014

Re: Email proposal to the

Martin Desruisseaux 10/20/2014

Re: Email proposal to the

Otávio Gonçalves de Santana 10/19/2014

Re: Email proposal to the

Werner Keil 10/19/2014

Re: Email proposal to the

Leonardo Lima 10/19/2014

Re: Email proposal to the

Werner Keil 10/20/2014

Re: Email proposal to the

Werner Keil 10/20/2014

Re: Email proposal to the

Otávio Gonçalves de Santana 10/20/2014

Re: Email proposal to the

Werner Keil 10/20/2014

Re: Email proposal to the

Martin Desruisseaux 10/20/2014
 
 
Close
loading
Please Confirm
Close