Skip to main content

[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: Wed, 20 May 2015 14:30:48 +0200

Dear Experts,

Further progress also comparing the BIPM brochure which is pretty much the
same as the 3 tables NIST published.

One exception we'd like to keep is *AngularSpeed *(previously
AngularVelocity) since GeoAPI references the latter, so we would like to
remain consistent with this downstream standard avoiding it to require
extra dependencies.

*Table 3* (Named Units/Quantities) is complete, the only difference is, we
called PlaneAngle simply Angle (also matching Wikipedia)

So of *Table 2* these 3 or 4 remain unsolved:

   - specific volume; cubic meter per kilogram m3/kg
   - current density; ampere per square meter A/m2
   - amount-of-substance concentration; mole per cubic meter mol/m3
   - mass fraction; kilogram per kilogram, which may be represented by the
   number 1 kg/kg = 1 (not sure, if that one really makes sense btw. as we
   have constants like ONE or Dimensionless already)

Please check them out if you consider them important enough for the API.
Again Table 2 is called "examples", so there's some room for interpretation
unlike 22 distinct quantities plus the 7 SI Base quantities and
Dimensionless (as well as the extra dependency for GeoAPI) we already got.

Thanks,
Werner

On Fri, May 15, 2015 at 6:48 PM, Werner Keil 
< >
 wrote:

> 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
>
>
>


[jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)

Werner Keil 05/15/2015

[jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)

Werner Keil 05/20/2015
 
 
Close
loading
Please Confirm
Close