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 12:48:48 +0200

The only case, where a ClassCastException could (and should[?]) happen, is
if you tried
Quantity<Area> squareHeight = height.multiply(height).asType(Area.class);

Quantity<Energy> bmi = mass.divide(squareHeight).asType(Energy.class); //
this should fail at runtime


There were examples, Martin mentioned earlier like "the most typesafe
alternative is to return 'Energy' directly, which indeed throw a
ClassCastException, but none of Jean-Marie's my or Martin's examples from
this recent thread would other than if you try to call asType() with an
incorrect target type/dimension.

Werner

On Tue, Oct 21, 2014 at 12:12 PM, Otávio Gonçalves de Santana <
>
 wrote:

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

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

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