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: Thu, 30 Oct 2014 10:23:44 +0100
Actually CDI was absolutely not "before Java 6" in fact it started making
EE 6 more modern and as you saw in the examples I mentioned it contains at
least as many Wildcard generics as 363;-)
Created by Gavin King initially, the guy behind Ceylon which similar to
Scala or Fantom (by a former 275 EG colleague;-) offers many improvements
Java is missing so far.
As an ME like approach to a standalone JDK module like Device I/O seems
best for this type of JSR why not talk to them about it. Regarding
generics, I may ask the current Spec Leads of CDI why they stick to <?>
even in V2;-)
Cheers,
Werner
Am 30.10.2014 08:48 schrieb "Otávio Gonçalves de Santana" <
>:
>
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
>
>
Attachment:
338.gif
Description: GIF image
Attachment:
329.gif
Description: GIF image
Attachment:
347.gif
Description: GIF image