Skip to main content

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

  • From: "Legrand, Karen" < >
  • To: " " < >
  • Subject: [jsr363-experts] Re: EDR done, next steps
  • Date: Fri, 30 Jan 2015 19:13:21 +0000
  • Accept-language: en-US

Maybe we should start by putting together a list of requirements that need to 
be tested. After reviewing the coverage, we could parcel those out for 
implementation.

From: Werner Keil 
[mailto: ]
Sent: Thursday, January 29, 2015 11:45 AM
To: 

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

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