Use Advanced Search to search the entire archive.
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