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



Re: Email proposal to the

(continued)

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

Re: Email proposal to the

Werner Keil 10/30/2014

Re: Email proposal to the

Martin Desruisseaux 10/30/2014

Re: Email proposal to the

Werner Keil 10/30/2014

Re: Email proposal to the

Martin Desruisseaux 10/30/2014

Re: Email proposal to the

Werner Keil 10/30/2014

Re: Email proposal to the

Martin Desruisseaux 10/30/2014

Re: Email proposal to the

Werner Keil 10/30/2014

Re: Email proposal to the

Otávio Gonçalves de Santana 10/31/2014

Re: Email proposal to the

Werner Keil 10/31/2014

Re: Email proposal to the

Werner Keil 10/19/2014

Re: Email proposal to the

Leonardo Lima 10/19/2014
 
 
Close
loading
Please Confirm
Close