Use Advanced Search to search the entire archive.
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: Thu, 30 Oct 2014 05:47:35 -0200
Thank you to explain Martin, but I don't feel comfortable when you use an
API in Java SE before 1.6 to explain Generics uses. I believe you did not
send the email to Core asking about the API.
If you mind, I send an email explain all context? This way the core team
can help us.
I know no, with work around to take care generics and remove the erasable
effects, maybe it can't make sense use the coringa operator.
On Wed, Oct 29, 2014 at 8:42 AM, Werner Keil
<
>
wrote:
>
Otavio/all,
>
>
Thanks for the additional clarification Martin. Potential or current users
>
(especially at Eclipse IoT) have also confirmed they understand what the
>
API does and that they are happy to use it. So maybe we could focus on
>
issues like https://java.net/jira/browse/UNITSOFMEASUREMENT-65 and
>
https://java.net/jira/browse/UNITSOFMEASUREMENT-67 which can improve user
>
experience even further and potentially give them a familiar feeling close
>
enough to JSR 354, the other "Value JSR" which this recent survey by a Java
>
Blogger ranked 5th in a Top 10 wish list for Java 9. Even before some of
>
the more "geeky" stuff OpenJDK is already known to have started and got a
>
JEP for[?]
>
>
http://www.takipiblog.com/350-developers-voted-for-features-in-java-9-have-they-decided-the-same-as-oracle/#more-659
>
>
I also clarified our position towards Java 9 or 10. The way Oracle added
>
Device I/O (actually under OpenJDK:
>
https://wiki.openjdk.java.net/display/dio/Main) to ME is where we would
>
ideally position this JSR beyond a 1.0 release. There is no JEP, and no JSR
>
(as Terrence suggested earlier, but I guess Oracle Chose a different path
>
for this[?]) but as you can see on the project page, Device I/O is
>
sponsored by the "core-lib" group. So if you really wanted to bother them
>
some day, maybe we should ask them when the time is right (after 1.0 is
>
Final or close to it see JSR 354) if they forsee a similar module as Device
>
I/O (which Embedded Solutions on ME and possibly SE will certainly use
>
together with this JSR) for Units and if we (outside Oracle) needed a JEP
>
for that. I trust V2COM's good relations with Oracle Embedded could also
>
help asking the right people the right questions[?]
>
>
Regards
>
>
Werner
>
>
>
>
>
On Wed, Oct 29, 2014 at 2:36 AM, Martin Desruisseaux <
>
>
>
wrote:
>
>
> Le 29/10/14 07:46, Otávio Gonçalves de Santana a écrit :
>
> > The problem is you are looking to actual implementation, maybe if we
>
> > used best strategies with generics it will not happen.
>
> It is not a matter of using better strategy. It is a matter of
>
> mathematics (in the sense of logic or set theories). There is no way a
>
> "better strategy" can make possible something mathematically impossible.
>
> For example there is no way a "better implementation" can solve a system
>
> of 2 equations with 3 unknowns.
>
>
>
> In the case of our problem, we don't even need to look at the
>
> implementation. There is no method signature with generic type that
>
> express how R is related to Q and T in a multiply operation. With this
>
> problem unsolved (and impossible to solve in current Java language), we
>
> know in advance that a type-safe parameterized multiply implementation
>
> is impossible.
>
>
>
> There is nothing wrong with wildcard, when used properly. Have you seen
>
> this standard Java method?
>
>
>
>
>
> http://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getEnclosingClass--
>
>
>
> The returns type is Class<?>, not Class<R> or whatever. This is not
>
> because of history, since other methods in the same class returns more
>
> accurate types (e.g. getSuperclass() returns Class<? super T>). They use
>
> wildcard because there is no way to express the relationship between T
>
> and the return value in the current Java language (they would need a
>
> Class<? enclosing T> bounds, which does not exist).
>
>
>
> 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


