Skip to main content

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 22:28:33 -0200

Werner we could remove from the apiece and keep in the implementation.
On Oct 19, 2014 10:10 PM, "Werner Keil" 
< >
 wrote:

> And just regarding the IoT guys at Eclipse, one asked about type-safety of
> these operations, but a choice of
> a) Cast
> b) asType()
> c) simply treat as <?>  where no type needs to be defined
> seems fine, not just to me.
>
> I asked them, if they accepted or preferred those methods removed, but
> they have not answered it yet.
>
> Last time they did, they said they would like no combined multiply() and
> asType() in one method, it did not sound, like they wanted them both
> removed;-)
>
> HTH,
> Werner
> Am 20.10.2014 02:04 schrieb "Werner Keil" 
> < >:
>
>> I asked them, and they should come back during office hours, maybe got
>> the question Thu or Fri.
>>
>> Please especially Martin/Jean-Marie, would you be happy to "split" the
>> API?
>> Both on Quantity AND Unit of course, because the "crux" meaning all <?>
>> methods, Otavio feels are inappropriate result from Unit;-)
>>
>> Ideally a simple Yes/No, similar to what I asked the IoT guys.
>> The question, if you prefer cast and where applicable asType() was
>> answered, and except a minor issue with SE8 and asType() I am happy with
>> that, too.
>>
>> Now what about removing every <?> method:
>> divide() and multiply(<?>) invert() and potentially pow() from both
>> Quantity and Unit?
>> Again, doing it just on Quantity won't solve the problem, the Unit ones
>> operate like that and those change the type.
>>
>> WDYT?
>> Am 20.10.2014 01:12 schrieb "Leonardo Lima" 
>> < >:
>>
>>> Werner,
>>>
>>> What Otávio meant was an issue to discuss how to deal with it, because
>>> he (still) thinks <?> is not ok.
>>>
>>> You keep saying that "most IoT projects at Eclipse would want them
>>> removed either", name one, two, three persons in these projects, let them
>>> join our group (if not as experts, at least in the other mailing lists) 
>>> and
>>> let them discuss with us, if /how should we deal with it so we all (EG and
>>> users) can play along...
>>>
>>> Regards,
>>> Leonardo.
>>>
>>> On Sun, Oct 19, 2014 at 9:02 PM, Werner Keil 
>>> < >
>>> wrote:
>>>
>>>> Nobody wants to remove them;-O
>>>> Neither Martin nor Jean-Marie, they want them to stay with <?> wildcard.
>>>> I doubt, most IoT projects at Eclipse would want them removed either.
>>>>
>>>> If something like asType() can be found for Quantity, that would be a
>>>> good thing to add;-) It works for Unit and in most cases it should also
>>>> work for Quantity. A pure Dimension check as currently done with Unit may
>>>> be a bit tricky here. Many custom types like BMI can be seen as
>>>> Dimensionless, but then if you declared such new quantities, will telling
>>>> BMI.class from CO2Footprint.class or HeartBeat.class all work?
>>>> Expressing them purely via Quantity<?> seems fine, taking care of
>>>> proper formatting is far trickier. I told you we must focus on that, at
>>>> least for SI types, so e.g. ThePerfectStorm dealing just with standard
>>>> quantities produces adequate results.
>>>>
>>>> Regards,
>>>> Werner
>>>> Am 20.10.2014 00:43 schrieb "Otávio Gonçalves de Santana" <
>>>>  >:
>>>>
>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>


Re: Email proposal to the

(continued)

Re: Email proposal to the

Werner Keil 10/21/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

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

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

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