Skip to main content

[jsr363-experts] Re: RI for Java ME

  • From: Werner Keil < >
  • To: " " < >
  • Subject: [jsr363-experts] Re: RI for Java ME
  • Date: Mon, 2 Nov 2015 11:15:43 +0100

Jean-Marie/all,

Thanks for your wishes and contribution by everyone.
With only 2 or 3 issues open (please see
https://java.net/jira/secure/RapidBoard.jspa?rapidView=12&view=planning) we
should be able to propose Public Review before DevoXX, ideally within about
a week from now.

Please have a look at the spec:
https://docs.google.com/document/d/12KhosAFriGCczBs6gwtJJDfg_QlANT92_lhxUWO2gCY/
for things you feel should be added or updated (the last thing also
accomplished was more taking things away into a separate RI guide;-)

There are some issues we may either solve ourselves (e.g. the best name for
"Bootstrap") or we could ask a hopefully decent crowd at DevoXX about them.
Similar to CDI I would personally find "UOM" a good alternative unless we
stick to a pattern defined by JSR 354 and leave it "Bootstrap" (at least
BeanValidation also has a similar class or interface with a similar purpose)

While missing the party T-shirt on Tuesday (not that I am short of
others;-) I attended another very good session by ARM's EC rep Zach Shelby
and Kona reviewer Darryl Mocek from Oracle about OpenJDK Project Kona:
http://openjdk.java.net/projects/kona/ Only COAP seems to have initial
contribution there yet, but that alone and others planned like "IEEE 11073
for Personal Health Devices" gave both of them an impression, JSR 363 could
fit in very well with these projects and efforts. I will get in touch with
both (and copy some of you, at least other Spec Leads and those already
involved in OpenJDK) to find out, how we may contribute the implementation
already aiming at OpenJDK: https://github.com/unitsofmeasurement/uom-se

Kona clearly consists of specialized "modules" for OpenJDK (mostly SE
Embedded some may also work with ME) similar to the somewhat related Device
I/O. So instead of waiting for OpenJDK 10 or 11 to contain something like
it under the Umbrella, it makes much more sense to offer type-safe Java
binding for Units of Measurement to support those other modules like COAP,
etc. Given the experience with JSR 275 we will not propose something like
that as RI at this point. It already is a compatible (passing all TCK tests
available) implementation. Maybe for Java ME 9 and above we could rethink a
future RI, but ME 9 isn't expected before 2017 either according to Oracle's
JavaOne announcements.

Cheers,
Werner

On Sat, Oct 31, 2015 at 1:45 PM, Jean-Marie Dautelle 
< >
wrote:

> Felicitation Werner ! This is wonderful news !!!
> Cheers,
> Jean-Marie.
>
> On Fri, Oct 30, 2015 at 4:26 AM, Werner Keil 
> < >
> wrote:
>
>> Dear Experts,
>>
>> Just in case anybody missed it, congratulations once more for JSR 363
>> winning the most significant JSR JCP Award this week at JavaOne.
>>
>> Those who were here are either already on their way back home or soon
>> leaving (I also do first thing tomorrow morning)
>>
>> During the last few sessions I took a closer look at RI issues related to
>> Java ME 8 Embedded.
>> A branch for that broke some number of unit tests while eliminating all
>> dependencies on methods or types not available in ME 8. Gradually merging
>> or re-applying them to the master one by one, I think there's a
>> breakthrough to get rid of pretty much all that's left.
>>
>> Calls to Math are substituted with a ME compliant helper class. At least
>> one method in Character is also substituted in a ME compliant way. A major
>> crux was the Field object, but it turns out, SimpleUnitFormat does have
>> quite some parse() functionality of its own, at least in a Locale-neutral
>> way. So enabling that for all relevant units (the key is also the label()
>> method here especially for new or derived units) looks like we can get rid
>> of EBNFUnitFormat at least in the ME compliant RI.
>> It has advantages for SE, so for a Java SE variant we should keep it.
>>
>> This looks like some helper classes and parser or token elements used by
>> SymbolMap / EBNFUnitFormat can probably be removed. And the RI size should
>> decrease, at least to around 150kb I would estimate. Thus the RI and API
>> together should be under 200k. If that is a problem for certain devices, we
>> may have to look into modularization of the RI, but first let`s see how to
>> get it running in the same way as the minimalistic enum implementation
>> already did.
>>
>> This is not a show-stopper for Public Review, but I am confident it can
>> be done in the course of next week or soon after. And we won't propose the
>> draft till another week or so giving the PMO and everybody else enough time
>> to recover from JavaOne.
>>
>> Regards,
>>
>>
>> Werner
>>
>
>
>
> --
> It is not the strongest of the species that survives, nor the most
> intelligent. It is the one that is most adaptable to change. - Darwin's
> Origin of Species (digest)
>


[jsr363-experts] Re: RI for Java ME

Werner Keil 11/02/2015

[jsr363-experts] Re: RI for Java ME

Werner Keil 11/04/2015

[jsr363-experts] Re: RI for Java ME

Werner Keil 11/05/2015

[jsr363-experts] Re: RI for Java ME

Leonardo Lima 11/06/2015

[jsr363-experts] Re: RI for Java ME

Werner Keil 11/08/2015

[jsr363-experts] Re: RI for Java ME

Werner Keil 11/09/2015

[jsr363-experts] Re: RI for Java ME

Leonardo Lima 11/10/2015

[jsr363-experts] Re: RI for Java ME

Werner Keil 11/10/2015
 
 
Close
loading
Please Confirm
Close