Skip to main content

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

  • From: Martin Desruisseaux < >
  • To:
  • Subject: Re: Email proposal to the
  • Date: Mon, 20 Oct 2014 23:48:39 +0900
  • Organization: Geomatys

Hello Werner

Le 20/10/14 20:08, Werner Keil a écrit :
> I am pretty sure, a semantic connection between input and output will
> never be available in Java.

I also believe that no such connection will be available in the
foreseeable future. For this reason, I believe that we should not omit
the multiply / divide / pow / invert methods, since I don't see when
they could be reintroduced with accurate type parameters. Consequently
if we keep those methods and choose to not remove completely
parameterized types in the whole project, I see only two solutions:

 1. The Quantity<?> / Unit<?> return type.
 2. Or add a Class<R> argument in multiply / divide / pow / invert methods..

If I'm understanding well, Werner told us that peoples on the Eclipse
side do not like option 2. I do not like option 2 neither. Furthermore,
option 2 imposes an unnecessary performance cost on users who do not
need to cast (i.e. on users who assign the result to a variable of type
Quantity<?>), or in intermediate calculation (i.e. in
A.multiply(B).divide(C), casting the multiplication result is useless
since it is not yet the final result).


> Reification of generics would add some benefit at runtime, it should
> work say after you call asType() which currently always returns Q, in
> a future Java version we might get Energy, Mass or Length instead, or
> Quantity<Energy>. Allowing implementing classes to check operations at
> runtime primarily. Other than the mentioned type annotations there is
> no way you could do this at compile time even with what Java may get
> via "Valhalla" or similar projects.

The fact that there is no way to get compile-time safety for the
multiply operation in current or foreseeable Java was the whole point
against UNITSOFMEASUREMENT-62 since the beginning (together with
"parameterized types shall not lie"). And I agree that reification of
generics will not change anything, since reification is not about
expanding the expressiveness power of Java parameter type syntax.


> Do you think asType() or whatever we'd call it there, works well in
> Quantity, too?

I think it should work well. But in my own opinion, letting the user
cast himself the result to a subtype like Energy looks cleaner. I will
try to demonstrate the feasibility on JavaSE 6, 7 and 8 after I start to
work on a RI clone.


    Martin



Re: Email proposal to the

(continued)

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