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: Wed, 29 Oct 2014 00:47:04 +0100
As mentioned, there are several popular APIs, most notably CDI:
http://docs.jboss.org/cdi/api/1.1/javax/enterprise/inject/spi/BeforeBeanDiscovery.html
takes <?>
http://docs.jboss.org/cdi/api/1.1/javax/enterprise/inject/spi/InjectionPoint.html
returns
Bean<?>.
CDI shows, there is no "best strategy" and as everyone involved for a long
time (especially Jean-Marie or Martin a bit longer than myself) confirmed,
the logical and semantical consistency is the "best strategy" to deal with
different quantities or dimensions as a result of arithmetic.
The JSR 363 API is portable, so from ME 8 to SE (not just 8, Eclipse is
also backward compatible to SE 6 in almost every module) and "similar"
platforms like Android it can and will be implemented. Especially Eclipse
projects not just UOMo or uDig start using it or (as the IP log is not
completed as of now) started using JSR-275 which is in Orbit already.
Especially for the Unit type being reasonably backward compatible is a good
sign of consistency.
Even with Java 11 or 21 it will not get "semantic rules" you would require
to decide if Unit1.multiply(Unit2) shall produce Unit3 or Unit4. Same for
Quantity, as it just routes relevant Unit operations.
If you really want to create something like that, in theory JSR 308
provides basic foundations. So far I have not seen it work properly with
non-primitive types, at least the Unit Checker. AFAIR the approach by Lex
Spoon (a former Google intern, Doug Lea mentoined his experiment) was much
closer to JSR-275 aside from a simplification of Quantity vs. Dimension
(also see the Spec Document comments) which Kennedy's F# library also
applies to a large extent.
So it is generallypossible to use JSR 308 on complex unit types, but the
authors of the Checker Framework (mostly EG members of JSR 308 plus a few
others) seem to have left that aside for now. One may argue, that this is
something Java 10+ Valhalla may solve with value types, but none of the
Valhalla goals alone, neither generics on primitive types, nor value types
or possible reified generics will help to answer the "Unit3 or Unit4"
question.
And such ruleset will always remain specific to a certain domain.
HTH,
Werner
On Tue, Oct 28, 2014 at 11:46 PM, Otávio Gonçalves de Santana <
>
wrote:
>
The problem is you are looking to actual implementation, maybe if we used
>
best strategies with generics it will not happen. About multiply units, in
>
this time the Erasable effect work to help us.
>
But I know, the focus is ME and not SE, so go a head, maybe we can submit
>
it to SE to Java 10 (when I hope the generics get more maturity).
>
>
On Tue, Oct 21, 2014 at 10:34 AM, Martin Desruisseaux <
>
>
>
wrote:
>
>
> Hello Otávio
>
>
>
> Le 21/10/14 19:12, Otávio Gonçalves de Santana a écrit :
>
>
>
> Martin, in your example can happen ClassCastException, in our case not,
>
> because we are using the same interface.
>
>
>
> In my example a ClassCastException can happen here:
>
>
>
> Integer r = (Integer) multiply(x, y);
>
>
>
> An no ClassCastException can happen here (potentially wrongly):
>
>
>
> Comparable<Integer> r = (Comparable<Integer>) multiply(x, y); // Unsafe
>
> cast
>
>
>
> In your example a ClassCastException can happen here (choose the
>
> alternative you prefer):
>
>
>
> Length r = (Length) speed.multiply(time);
>
> Length r = speed.multiply(time).cast(Length.class);
>
>
>
> An no ClassCastException can happen here (potentially wrongly):
>
>
>
> Quantity<Length> r = (Quantity<Length>) speed.multiply(time); // Unsafe
>
> cast
>
>
>
> Where do you see a behavioural difference? And what do you mean by
>
> "because we are using the same interface"? In my example too all classes
>
> extends Comparable, and all arguments and return value are Comparable.
>
>
>
>
>
> 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?
>
>
>
> Yes. Here:
>
>
>
> 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<>();
>
> }
>
> }
>
>
>
> The compiler accepts this code because you are not assigning any unit to
>
> BigDecimalQuantity. If you try to assign a Unit<E> to that
>
> BigDecimalQuantity, you are faced to the following problems:
>
>
>
> - The parameterized type of Quantity unit is the same as the
>
> parameterized type of the quantity.
>
> - Consequently, the parameterized type of the unit of the
>
> BigDecimalQuantity you are constructing must be <E>.
>
> - The parameterized type of the Unit computed by that multiply
>
> function is <?> (attempts to "fix" Unit.multiply(Unit) will just lead
>
> to a similar bullet list than this one).
>
> - That multiply method has absolutely no way to know that the Unit<?>
>
> can be safely casted to Unit<E>. The only way to verify that in
>
> current Java would be to have a Class<E> argument.
>
> - Consequently multiply can not proceed, end of the story.
>
>
>
> Even if we could check the type inside the multiply method, this is not
>
> the way parameterized types are supposed to work. Except for a few
>
> special-purpose methods like Class.asSubclass(Class) or
>
> Unit.asType(Class), The purpose of parameterized type is to guarantee
>
> that no ClassCastException will be thrown if the error compiled without
>
> errors and without "unsafe cast warnings".
>
>
>
> I challenge you to write a complete multiply implementation with your
>
> method signature without "unsafe cast" warning that you can not prove to be
>
> safe. If you succeed, I retire everything I told in this whole threat,
>
> would own you all my apologize, send flowers, ton of chocolate, wash your
>
> car, etc.
>
>
>
> The fact that a method is impossible to implement without unprovable
>
> "unsafe cast" warnings is a much, much more serious sign of critical design
>
> flaw than the presence of <?> in a return value.
>
>
>
> 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
>
>