Skip to main content

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

  • From: Werner Keil < >
  • To: " " < >
  • Subject: [jsr363-experts] Re: EDR done, next steps
  • Date: Sat, 31 Jan 2015 14:32:53 +0100

Actually the best place for such requirements or a "test plan" is a file
like https://github.com/JavaMoney/jsr354-tck/blob/master/test-audit.xml
We got a smaller one here
https://github.com/unitsofmeasurement/unit-tck/blob/master/test-audit.xml
While the Spec only has sections or headers on the 1st level, everything
else needs to be retrieved and looked up by the number of sub-headers, this
file allows us to gather actual tests. And then refer to them in the actual
test. Please feel free to populate the file. It should in most cases match
a similar or identical chapter of the Spec.

Thanks,
Werner

On Fri, Jan 30, 2015 at 9:08 PM, Werner Keil 
< >
 wrote:

> P.s.: Google Docs unfortunately doesn't seem to offer default numbering of
> headers, but converting to OpenOffice or Word lets you check the number and
> depth of headlines underneath the top level. Should we some day migrate to
> Asciidoc or something similar, there some more levels can be numbered.
>
> On Fri, Jan 30, 2015 at 9:05 PM, Werner Keil 
> < >
> wrote:
>
>> 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