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 10:39:43 +0200

Martin/all,

I am not sure, if you still want to proceed with that mail to the OpenJDK
Team, or is it more a clarification for Otavio?

On Tue, Oct 21, 2014 at 10:11 AM, Martin Desruisseaux <
>
 wrote:

>  Hello Otávio
>
> Le 21/10/14 04:27, Otávio Gonçalves de Santana a écrit :
>
>  But Martin, if you don't explain exactly, the help will not valuable.
> Because our problem happens because the Erasable effect.
>
> The erasable effect is exactly the same with the example that I provided.
> This is the exact same thing with only different names (e.g. Quantity ->
> Comparable, Length -> Integer, Time -> Short), with some classes (Integer/
> Short) instead than interfaces (but it doesn't make any difference for
> parameterized types) and a different relationship between R and (X,Y).
>
> If you can point me to a behavioural difference regarding casting and
> parameter types, I will abandon the Comparable example. But for now I see
> none. All conclusions done on the Comparable example apply also to
> Quantity because all differences between the two examples (name, class vs
> interface, multiply(x,y) implementation details) are irrelevant to our
> problem.
>
> However I could add a section saying "Some members feel that knowledge of
> the actual JSR interfaces may change the perspective", and provide the
> speed = length/time example. I'm pretty sure that the answer will be that
> it makes no difference.
>
>
>  Maybe the best strategy would remove temporarily, when when it will fix
> the method go back or keep the new method signature and when possible take
> care the semantic.
>
> The UNITSOFMEASUREMENT-62 method signatures can not come back: they are
> logically wrong. If the JSR group went ahead with UNITSOFMEASUREMENT-62, I
> would point that flaw to the JCP and I'm sure that it would cause a massive
> amount of "no" votes. This is not a Java language limitation. It is
> mathematical (if we accept the "*parameterized types shall not lie*"
> rule) - it goes beyond all programming languages.
>
> However a new method signature could be back in a different form if the
> Java language was extended in a way allowing us to apply operations on
> parameter types beyond the standard "<X extends Y>" and "<X super Y>"
> operators. However I'm not aware of any plan in the foreseeable future.
> Java generic reification is not about that, so it will not change anything
> to the method signature problem. Consequently, if we omit those method and
> wait for an improved Java generic systems, we may wait for a very long time.
>
>
>  IMHO: In Java API is easier add a method and or create a new
> implementation take care the type, when the Erasable gonna fix, instead
> just change a signature.
>
> This is not a problem with type erasure. This is a problem with the
> expressiveness power of the Java parameterized type syntax. When generic
> types will be reified, the only difference is that the (Quantity<Mass>)
> cast will not be unsafe anymore. But the UNITSOFMEASUREMENT-62 method
> signature still a big no-no because it still lying, and the user will still
> have to cast himself.
>

+1
While the shortcut proposed by #62 was appealing from a user's Point of
view at first, it can be accomplished perfectly fine now via a combination
of existing methods.
I added asType() to Quantity, it was there all the time in
AbstractQuantity, especially in the SE port, so even if a majority insisted
on cropping it from the API one could still use it via RI or SE
implementation (with the inconvenience of having to cast or use the
implementation class instead of Quantity[?])
See
https://github.com/unitsofmeasurement/uom-demos/blob/master/domain/health/src/main/java/tec/uom/demo/health/BMIDemo.java
The known  quantities like say Area work perfectly fine with asType(),
there is no cast necessary, if so the implementation will do it for you,
otherwise a ClassCastException is thrown.
For BMI it is a new/unknown type. Which requires no cast either. Only if
you wished to cast, it is necessary and the Compiler raises a warning.
Undoing this warning with a "hack" is the Problem the approach to #62 had.

Werner


>
>     Martin
>
>

Attachment: 347.gif
Description: GIF image



Re: Email proposal to the

(continued)

Re: Email proposal to the

Martin Desruisseaux 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

Otávio Gonçalves de Santana 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/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
 
 
Close
loading
Please Confirm
Close