Use Advanced Search to search the entire archive.
[jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)
- From: Chris Senior <
>
- To:
- Subject: [jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)
- Date: Wed, 08 Apr 2015 13:51:13 +0000
What is the relative overhead or cost of option 2 vs. option 1; and option
3 vs. option 2?
On Tue, 7 Apr 2015 at 17:14 Werner Keil
<
>
wrote:
>
Jean-Marie/all,
>
>
Thanks for the quick reply.
>
*si.uom* is not the RI: https://github.com/unitsofmeasurement/si-units On
>
the contrary. It allows to hold everything that won't remain in the API but
>
is used or "accepted by SI" in an implementation neutral form. Unless there
>
are concrete classes like "SI" or others these reusable type libraries
>
contain nothing but additional interfaces to be compatible across all
>
implementations.
>
>
Cheers,
>
Werner
>
>
>
On Tue, Apr 7, 2015 at 5:45 PM, DAUTELLE, Jean-Marie <
>
>
>
wrote:
>
>
> Hi Werner and All,
>
>
>
> 3. SI derived quantities (in javax.measure.quantity) +
>
> Dimensionless s. Table 2 (and mostly CLDR, too)
>
>
>
> We should stick with NIST Reference as much as we can. We have the chance
>
> to have an internationally recognized body to work with; let’s not reinvent
>
> the wheel.
>
>
>
> Also, these are typically the classes/interfaces which are the most
>
> important in the API (none of them should be in the RI).
>
>
>
>
>
>
>
> Cheers,
>
>
>
> Jean-Marie.
>
>
>
>
>
>
>
> *From:* Werner Keil
>
> [mailto:
]
>
> *Sent:* mardi 7 avril 2015 15:27
>
> *To:*
>
>
>
> *Subject:* [jsr363-experts] [VOTE] Define quantities to remain in API
>
> (see UOM-100)
>
>
>
>
>
>
>
Dear Experts,
>
>
>
>
>
>
>
> I hope you had a nice Easter holiday. Aside from brushing JSR 354 (which
>
> is heading towards Final pretty soon) I worked on the tools for analysis
>
> and comparison of different unit data sources which also lead to decision
>
> making of https://java.net/jira/browse/UNITSOFMEASUREMENT-100
>
>
>
>
>
>
>
> To get the core API even slimmer and a common understanding of quantities
>
> we would like there if any, I spawned-off a true SI module with a draft of
>
> all quantities currently in javax.measure:
>
> https://github.com/unitsofmeasurement/si-units/tree/master/quantity/src/main/java/si/uom/quantity
>
>
>
>
>
>
>
> uom.si is among the domains registered and while many folks and projects
>
> now rush towards their "io" domain (it's also a territorial domain btw. and
>
> exists for nearly 20 years http://en.wikipedia.org/wiki/.io) I got us "
>
> uom.si" (http://en.wikipedia.org/wiki/.si for Slovenia, other than
>
> Pepsi, there is nearly no company or project outside that country, which
>
> makes the domain a lot cheaper than "io" ;-) as a fairly unique place
>
> dedicated to SI units.
>
>
>
>
>
>
>
> Based on the NIST overview http://physics.nist.gov/cuu/Units/units.html
>
> please reply with your (+1) preference of having:
>
>
>
>
> 1. Nothing except Dimensionless (probably best in the SPI package)
>
>
>
> 2. Only the 7 SI Base quantities plus Dimensionless (in
>
> javax.measure.quantity) s. Table 1
>
>
>
> 3. SI derived quantities (in javax.measure.quantity) +
>
> Dimensionless s. Table 2 (and mostly CLDR, too)
>
>
>
in the API?
>
>
>
>
>
>
>
> The delta from currently around 50 quantities should move to the SI
>
> module as long as they're commonly accepted for use with the SI system,
>
> e.g. http://physics.nist.gov/cuu/Units/outside.html
>
>
>
> This quantity catalogue is as platform-independent as the API itself, so
>
> RI, SE Port and other implementations may use it where appropriate. The RI
>
> will however probably stick to those few quantities we decide to keep in
>
> the API. While uom-se or other projects and implementations can use the
>
> extended SI catalog or additional quantities (to be defined elsewhere,
>
> likely under the non-SI UOM umbrella)
>
>
>
>
>
>
>
> Thanks,
>
>
>
>
>
> Werner
>
>
>
>
> The information in this e-mail is confidential. The contents may not be
>
> disclosed or used by anyone other than the addressee. Access to this
>
> e-mail by anyone else is unauthorised.
>
> If you are not the intended recipient, please notify Airbus immediately
>
> and delete this e-mail.
>
> Airbus cannot accept any responsibility for the accuracy or completeness
>
> of this e-mail as it has been sent over public networks. If you have any
>
> concerns over the content of this message or its Accuracy or Integrity,
>
> please contact Airbus immediately.
>
> All outgoing e-mails from Airbus are checked using regularly updated virus
>
> scanning software but you should take whatever measures you deem to be
>
> appropriate to ensure that this message and any attachments are virus free.
>
>
>
>
>