Skip to main content

[jsr363-experts] EDR done, next steps

  • From: Werner Keil < >
  • To: " " < >
  • Subject: [jsr363-experts] EDR done, next steps
  • Date: Thu, 29 Jan 2015 18:44:40 +0100

Dear Experts,

As you may know, EDR finished yesterday. Thanks everybody who helped with
any relevant part at this stage. Therefore the ticket for EDR
https://java.net/jira/browse/UNITSOFMEASUREMENT-82  is now closed.

Except the somewhat inconsistent (though correct against the Spec, so
having no symbol or name for derived units is perfectly fine from the point
of the Unit interface or Spec;-) behavior between units defined by RI
elements (mostly unit systems) and pure parsing/marshaling of the same
defined by UCUM.

Removing UCUM from the RI and focusing on other definitions like those in
the Unicode CLDR (most likely with just a "default" language for ME, could
leverage Unicode's power and 70+ languages in SE, but for small devices
that seems an overkill) seems like a good idea. Not that UCUM is bad, but
it is bound to a large XML file while even the native unprocessed CLDR data
comes as JSON, which has some support by ME 8, too and for actual usage we
should bring it into a suitable format for the RI (either a class,
properties or similar)

Since even those in the EC who may not review all JSRs in greater detail
heard our presentation and saw the material, it is reasonable to believe,
had any of them felt uneasy about a particular aspect, they would have said
so either during the F2F or via mailing lists.

Since there were no significant issues raised other than the UCUM one (and
a few bugs all fixed by now) we don't seem to benefit much from an Early
Draft 2. One of the most important pieces to work on is the TCK, see
https://java.net/jira/browse/UNITSOFMEASUREMENT-101 and its sub-tasks.

I encourage especially those who provided a lot of input into the spec and
API/RI before Early Draft to help with the TCK. It is proof of relevant
statements and definitions in the Spec regarding implementations. Take a
small example from JSR 354 in
https://github.com/JavaMoney/jsr354-tck/blob/master/src/main/java/org/javamoney/tck/tests/ModellingCurrenciesTest.java

  /**
     * Ensure at least one javax.money.CurrencyUnit implementation
     * is available and registered/accessible from MonetaryCurrencies.
     */
    @SpecAssertion(section = "4.2.1", id = "421-A1")
    @Test(description = "4.2.1 Ensure TCK has CurrencyUnit classes
configured.")
    public void testEnsureCurrencyUnit(){
        AssertJUnit.assertTrue("TCK Configuration not available.",
TCKTestSetup.getTestConfiguration() != null);

AssertJUnit.assertTrue(TCKTestSetup.getTestConfiguration().getCurrencyClasses().size()
> 0);
    }
Based on
https://github.com/JavaMoney/jsr354-api/blob/master/src/main/asciidoc/JavaMoneySpecification.adoc#CoreAPI
in the Spec.

Essentially it checks there is at least one implementation of a
CurrencyUnit.

We'd have similar assertions, e.g. that a SystemOfUnit implementation must
be present and either that or comparable implementation classes like
Quantities return at least one Quantity implementation, etc.

Where actual standards like SI/BIPM, ISO or at least CLDR specify which
particular units make a proper unit system, such assessments would also
make sense regarding the size / completeness of certain unit collections.

Based on my Eclipse CQ the Eclipse SmartHome project also just filed their
intent to use the JSR from Orbit. That's good support. Probably others
follow (at least UOMo;-) and there are some interesting Embedded/IoT
projects ike Kura or COAP there, too. Kura even explored Oracle's Device
I/O on Java SE Embedded.

Should e.g. the UOM-SE port suffer lack of interest or resources, then of
course some de-scoping of e.g. the UCUM parts may occur there, too. It is
not a core part of the JSR, so it does not affect our mandatory output. Of
course it would be nice as we also stated to have one or the other
implementation that can be verified by the TCK, too;-)

Regards,

Werner


[jsr363-experts] EDR done, next steps

Werner Keil 01/29/2015

[jsr363-experts] Re: EDR done, next steps

Legrand, Karen 01/30/2015

[jsr363-experts] Re: EDR done, next steps

Werner Keil 01/30/2015

[jsr363-experts] Re: EDR done, next steps

Werner Keil 01/30/2015

[jsr363-experts] Re: EDR done, next steps

Werner Keil 01/31/2015
 
 
Close
loading
Please Confirm
Close