Use Advanced Search to search the entire archive.
[jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)
- From: Werner Keil <
>
- To: "
" <
>
- Subject: [jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)
- Date: Fri, 15 May 2015 18:48:50 +0200
Dear Experts,
Please review
https://java.net/jira/browse/UNITSOFMEASUREMENT-100 with the
latest attachment (Excel sheet with all 3 NIST tables and whether they
exist in the API as of now.
All SI Base Units and Quantities obviously exist, so Table 1 is a
no-brainer.
From Table 2 *MassDensity *(also see
https://java.net/jira/browse/UNITSOFMEASUREMENT-9) exists under a different
name *VolumetricDensity *already.
If you think the name was better than MassDensity, please comment here or
in
https://java.net/jira/browse/UNITSOFMEASUREMENT-9, we could then close
it with "Won't fix" if we prefer VolumetricDensity.
Further
- SpecificVolume
- CurrentDensity
- AmountOfSubstanceConcentration
- MassFraction
are not included in the API. Especially the latter "which may be
represented by the number 1" is somewhat exotic. And constants like "ONE"
both exist for Unit and Quantity, so not sure, if either of those are worth
adding to the base API. Please reply with "+1 <QuantityIWouldLikeToSee>"
either here or in
https://java.net/jira/browse/UNITSOFMEASUREMENT-100
From Table 3 *PlaneAngle *does not exist in javax.measure.quantity. Please
advise on whether we should add it (here or as comment in
https://java.net/jira/browse/UNITSOFMEASUREMENT-100) See Notes for
different names, but in most cases, I'd say the current quantity names are
OK, share your thoughts if you disagree.
All Quantity types that are in the API package but not in either of these
tables are now @deprecated, so are their usages in the SI class (which
based on this reduction should go away and the RI system class be called
"Units" if nobody objects. All excess quantities shall move to a separate
extension "si.uom" under a distinct package space (
https://github.com/unitsofmeasurement/si-units)
Similar to ways, Java SE 8 selects different Date/Time/Calendar sources
including Unicode CLDR
http://docs.oracle.com/javase/8/docs/technotes/guides/intl/enhancements.8.html#cldr
There is an item to define something similar, see
https://java.net/jira/browse/UNITSOFMEASUREMENT-121.
Allowing something like "
javax.measure.unitsystemproviders=NIST,SPI,SI,CLDR,UCUM"
The default behavior is equivalent to the following setting: "
javax.measure.unitsystemproviders=NIST,SPI"
Just a draft how it may be controlled, including the names for these
settings or providers.
Thanks and Regards,
Werner