Skip to main content

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

  • From: Werner Keil < >
  • To: " " < >
  • Subject: [jsr363-experts] Re: EDR done, next steps
  • Date: Fri, 30 Jan 2015 21:05:10 +0100

As seen by JSR 354 (the @SpecAssertion annotations by JBoss help further
clarify that, but tests would also be OK without them) every requirement
should be in the Spec;-)

So one of our Spec paragraphs like 5.4 Supported quantities
we'd check the SI system, if all quantity types from that list are returned
by the getUnits() collection.
Of course such test would need to apply only to a profile containinng both
"quantity" and "spi", so we also neeed to categorize tests appropriately
and define some profile (likely by using Maven profiles)

Similar to the most basic tests in JavaMoney TCK a "core" test against 5.2
The Unit Interface could be if at least one implementation of Unit exists.
Actually some basic structures like the ServiceConfiguration interface
already exist in the TCK with methods like getQuantityClasses() or
getUnitClasses().

The "core" tests simply check that Quantity and Unit are "at leasts once"
implemented, while extended tests against "quantity" or SPI check in more
detail against the supported quantities. The discussion I had with Mark
Reinhold at the recent F2F clarified  that an implementation making full
use of "quantity" should expose all these quantities. Whether ornot we may
further diversify the TCK, we may see, but the package must always contain
all interfaces, the idea of "stripping" was abandoned by Oracle. And we
would not want to create a separate package for each quantity now to allow
"mix & match", that would be an overkill;-D
Whether we reduced the number of  quantities, especially now that UCUM is
no longer in the RI, that's probably a good follow-up JIRA task and
discussion item.

Regards,
Werner

On Fri, Jan 30, 2015 at 8:13 PM, Legrand, Karen 
< >
wrote:

>  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