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: Tue, 21 Oct 2014 08:12:48 -0200

Martin, in your example can happen ClassCastException, in our case not,
because we are using the same interface.
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?
I believe our problem is about semantic and you would be cool say our
scenario.


public interface Quantity<Q extends Quantity<Q>> {

<T extends Quantity<T>, E extends Quantity<E>> Quantity<E>
multiply(Quantity<T> that);
}

public interface Mass extends Quantity<Mass> {

}

public interface Speed extends Quantity<Speed> {

}

public interface  Length extends Quantity<Length>{

}

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<>();
}

}

On Tue, Oct 21, 2014 at 6: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.
>
>     Martin
>
>


-- 
Otávio Gonçalves de Santana

blog:     http://otaviosantana.blogspot.com.br/
twitter: http://twitter.com/otaviojava
site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
55 (11) 98255-3513


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

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
 
 
Close
loading
Please Confirm
Close