Use Advanced Search to search the entire archive.
Tasks for EDR
- From: Werner Keil <
>
- To: "
" <
>
- Subject: Tasks for EDR
- Date: Mon, 6 Oct 2014 19:30:59 +0200
Dear Experts,
Just closed the "JavaOne" sprint after returning from JavaOne and related
F2F meetings.
Thanks for all who attended the F2F meeting during JavaOne or Hackergarten,
etc.
An important outcome I'd like to apply if none of the EG members who were
not in the meeting or joined remotely object is the license change. See:
https://java.net/jira/browse/UNITSOFMEASUREMENT-58
The reason is, that future versions of platform components including
OpenJDK could find some of the functionality here useful. Oracle started
factoring out its Device Access API into a "jdk.*" package. Also related
to the platform. While not a JSR right now, it aims to provide packages
available to both ME and SE alike. Something similar could use JSR 363 and
it is not unthinkable, a "jdk.something" package dedicated to sensor and
measurement values also exists in the near future. Maybe not Java 9, but
who knows.
As Oracle (Legal) currently considers Apache licensed code a no-go for such
platform projects and (until Jim Wright then had a slightly different view
of the Apache license as he does now;-) all relevant Unit-API code that did
not fall under a Spec License was BSD before, there is no reason not to go
back to BSD, especially for key components like RI, TCK or alternate ports
like the SE one.
There are a few other items, the Spec Document probably the most important
one for EDR.
Formatting (not yet filed) is also important.
I filed Jean-Marie's claim, that inverse() returns a wrongly typed
quantity. It should be wildcard, too.
As mentioned, some simple examples of mixed calculations like BMIDemo:
Quantity<Length> height = Quantities.getQuantity(1.87d, METRE);
Quantity<Mass> mass = Quantities.getQuantity(85d, KILOGRAM);
Quantity<?> squareHeight = height.multiply(height);
Quantity<?> bmi = mass.divide(squareHeight);
System.out.println(bmi);
demonstrate, a "BMI" type (class, etc.) does not have to exist especially
in constrained environments for this calculation to be succesful and
productive to users.
Even formatting works perfectly well:
24.307243558580453 kg/m²
with default toString() and no extra format applied.
Especially asType() in Unit showed to be rather cumbersome under Java SE 8
in places, where everything worked. Therefore any experiments regarding
enhanced typing should ideally happen in the SE port for now[?] Whether that
used JSR 308 or something else, I can't say. Anyway, it is likely out of
scope for the core JSR to remain portable across platforms, e.g. 308 is
unlikely to ever make its way into ME.
I do not have regular desktop connection to internet while in Vienna, but a
few times a week I am either in a web cafe, "hacker lab" (where JUGs and
other communities meet regularly in Vienna;-) or similar places. Maybe
towards the end of the month we could try a Hangout or call again. It
should not be too soon after the recent meeting.
None of that would prevent EDR, but if we got a sustainable answer to the
ME 8 Embedded "bug" (which could be either ME SDK 8.x or NetBeans related,
but other than using older versions of API and impl there is so far no
remedy) before publishing EDR it would of course be a good thing.
https://java.net/jira/browse/UNITSOFMEASUREMENT-3 and its 2 remaining open
sub tasks are important to get away. Formatting improvements where
possible. Again, the RI may not aim to answer every single question and use
case, take JSR 107 or others with multiple implementations or Glassfish vs.
WebLogic for Java EE (if Glassfish covered every industry need already, who
would still by WL?[?])
If a TCK started it would be cool, but don't forget, EDR is the first
stage, and we have quite a few things in place other than that by now.
Leonardo mentioned some Hackathon in Brazil, Hackergarten should also take
place at JMaghreb, so I could probably schedule something for MoroccoJUG.
We should publish EDR by the end of the year to stay on track with JCP.next
requirements. Aside from a few minor tweaks to the Spec document, there is
nothing we'd be missing of mandator EDR requirements as of now[?]
Regards,
Werner
Attachment:
329.gif
Description: GIF image
Attachment:
347.gif
Description: GIF image
Tasks for EDR
|
Werner Keil |
10/06/2014 |