Use Advanced Search to search the entire archive.
[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