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: Wed, 8 Apr 2015 20:20:16 +0200
Thanks.
Different sources have different names, but most CLDR-provided quantities
acceleration angle area digital consumption electric electric
electric energy frequency light length mass power pressure
proportion temperature duration speed volume
match
(proportion and byte/information are not in NIST/SI scope, but we may
include especially Information for IT purposes)
I'll attach an Excel sheet nist_units to the JIRA ticket. It contains the
units in "Table 1" and "Table 2" for clarity.
We'll consider all 20 including the 12 derived ones, unless somebody has
serious objections. Given Unicode offers a treasure chest of translations
for free, it may be a good idea to take its 2 or 3 extra quantities beyond
the 2 NIST tables also, but feel free to suggest alternatives.
The RI will likely not offer a large number of translations, that's more
for uom-se, since CLDR can get up to several kB or even MB (just look at
ICU4J)
Cheers,
Werner
On Wed, Apr 8, 2015 at 7:31 PM, Chris Senior
<
>
wrote:
>
If we are talking 10 KB or less of overhead in terms of declared classes
>
in the VM - then I vote option 3 too.
>
>
Can we be explicit (in JIRA?) about the final list of Quantities that
>
would be in the API - I don't understand the references to the links
>
provided?
>
>
On Wed, 8 Apr 2015 at 15:21 Werner Keil
>
<
>
>
wrote:
>
>
> You mean in terms of memory?
>
>
>
> So far the 50 quantities have a footprint of roughly 20kb. So splitting
>
> them in half (option 3) would mean around 10kb instead.
>
> Option 2 more or less 1/4, so say 5k, and option 1 would mean almost no
>
> footprint except the Dimensionless type.
>
>
>
> About the TCK, judging from e.g. what 354 did, we should test, that an
>
> implementation of SystemOfUnits supports a given number of quantity types
>
> via
>
> getUnit(Class<Q> quantityType)
>
>
>
> I am not sure, if we'd force any 3rd party implementation to include
>
> particular quantities, maybe we also just assess, whether or not getUnits()
>
> returns a non-null, non-empty result, or not. That's a good point for the
>
> TCK, but unless we narrow it down to e.g. the 7 SI base units, I don't
>
> think a custom unit system for e.g. Health, Smart Home, etc. should be
>
> forced to support a certain number of quantities to pass the TCK, thus
>
> there seems less overhead. If we declare say 8 or 20 quantity types, there
>
> could be tests to verify they are used, but e.g. the Quantities factory
>
> class is not part of the API, so a TCK may not have to consider that one
>
> present either.
>
>
>
> Does that help?
>
>
>
> On Wed, Apr 8, 2015 at 3:51 PM, Chris Senior <
>
>
>
>
> wrote:
>
>
>
>> 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.
>
>>>>
>
>>>>
>
>>>
>
>