Skip to main content

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

  • From: Werner Keil < >
  • To: " " < >
  • Subject: Re: Email proposal to the
  • Date: Tue, 21 Oct 2014 14:52:33 +0200

On Tue, Oct 21, 2014 at 2:34 PM, Martin Desruisseaux <
>
 wrote:

>  Hello Otávio
>
> Le 21/10/14 19:12, Otávio Gonçalves de Santana a écrit :
>
>  Martin, in your example can happen ClassCastException, in our case not,
> because we are using the same interface.
>
> In my example a ClassCastException can happen here:
>
> Integer r = (Integer) multiply(x, y);
>
>  An no ClassCastException can happen here (potentially wrongly):
>
> Comparable<Integer> r = (Comparable<Integer>) multiply(x, y);  // Unsafe 
> cast
>
>  In your example a ClassCastException can happen here (choose the
> alternative you prefer):
>
> Length r = (Length) speed.multiply(time);
> Length r = speed.multiply(time).cast(Length.class);
>
>
This is highly discouraged as it won't work unless you also implement
Length in a dedicated class like LengthAmount,...
 Also see this library:
https://github.com/unitsofmeasurement/uom-lib/tree/master/si

For every General purpose Quantity implementation, specific Interfaces like
Length are simply generic specializations at compile time (Java so far
won't Keep them until it may get reification of generic types[?]) See them
as "Annotation like" (after all annotations are also some specialized
@interface and look at CDI they can indeed be used in places where you
normally won't find them[?]) or "sup-type" of a quantity, but they are
normally not meant to be directly used.

 An no ClassCastException can happen here (potentially wrongly):
>
> Quantity<Length> r = (Quantity<Length>) speed.multiply(time);  // Unsafe 
> cast
>
>  Where do you see a behavioural difference? And what do you mean by
> "because we are using the same interface"? In my example too all classes
> extends Comparable, and all arguments and return value are Comparable.
>
>
The safe alternative would now be

Quantity<Length> r = speed.multiply(time).asType(Length.class);

And it is the preferred way for "mixed operations" unless you want to do a
calculation that may result in dimensionless or otherwise non-SI results.
Then either use Quantity<?> since you don't care about the subtype of the
result, or perform an explicit, but unsafe cast as above[?]

Werner


>  I did a brief of the code below, I am just using Generics with diamond
> resources, available in Java 7 or above. Can you show me how may happen the
> same thing with this code or the cast could be unsafe?
>
> Yes. Here:
>
> public class BigDecimalQuanity<Q extends Quantity<Q>> implements
> Quantity<Q> {
>  public <T extends Quantity<T>, E extends Quantity<E>> Quantity<E>
> multiply(Quantity<T> that) {
>  return new BigDecimalQuanity<>();
>  }
> }
>
> The compiler accepts this code because you are not assigning any unit to
> BigDecimalQuantity. If you try to assign a Unit<E> to that
> BigDecimalQuantity, you are faced to the following problems:
>
>    - The parameterized type of Quantity unit is the same as the
>    parameterized type of the quantity.
>    - Consequently, the parameterized type of the unit of the
>    BigDecimalQuantity you are constructing must be <E>.
>    - The parameterized type of the Unit computed by that multiply
>    function is <?> (attempts to "fix" Unit.multiply(Unit) will just lead
>    to a similar bullet list than this one).
>    - That multiply method has absolutely no way to know that the Unit<?>
>    can be safely casted to Unit<E>. The only way to verify that in
>    current Java would be to have a Class<E> argument.
>    - Consequently multiply can not proceed, end of the story.
>
> Even if we could check the type inside the multiply method, this is not
> the way parameterized types are supposed to work. Except for a few
> special-purpose methods like Class.asSubclass(Class) or Unit.asType(Class),
> The purpose of parameterized type is to guarantee that no
> ClassCastException will be thrown if the error compiled without errors
> and without "unsafe cast warnings".
>
> I challenge you to write a complete multiply implementation with your
> method signature without "unsafe cast" warning that you can not prove to be
> safe. If you succeed, I retire everything I told in this whole threat,
> would own you all my apologize, send flowers, ton of chocolate, wash your
> car, etc.
>
> The fact that a method is impossible to implement without unprovable
> "unsafe cast" warnings is a much, much more serious sign of critical design
> flaw than the presence of <?> in a return value.
>
>     Martin
>
>

Attachment: 329.gif
Description: GIF image

Attachment: 347.gif
Description: GIF image



Re: Email proposal to the

(continued)

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/21/2014

Re: Email proposal to the

Martin Desruisseaux 10/21/2014

Re: Email proposal to the

Werner Keil 10/21/2014

Re: Email proposal to the

Martin Desruisseaux 10/21/2014

Re: Email proposal to the

Werner Keil 10/21/2014

Re: Email proposal to the

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

Re: Email proposal to the

Werner Keil 10/21/2014

Re: Email proposal to the

Martin Desruisseaux 10/21/2014

Re: Email proposal to the

Werner Keil 10/21/2014

Re: Email proposal to the

Martin Desruisseaux 10/21/2014

Re: Email proposal to the

Werner Keil 10/21/2014

Re: Email proposal to the

Werner Keil 10/21/2014

Re: Email proposal to the

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

Re: Email proposal to the

Werner Keil 10/28/2014

Re: Email proposal to the

Martin Desruisseaux 10/29/2014

Re: Email proposal to the

Werner Keil 10/29/2014

Re: Email proposal to the

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

Re: Email proposal to the

Werner Keil 10/30/2014

Re: Email proposal to the

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