Use Advanced Search to search the entire archive.
[jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)
- From: Leonardo Lima <
>
- To: "
" <
>
- Subject: [jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)
- Date: Mon, 20 Apr 2015 10:37:02 -0500
Hello!
I posted on the JIRA issue; I +1 what Jean-Marie said.
Regards,
Leonardo.
On Wed, Apr 8, 2015 at 1:20 PM, Werner Keil
<
>
wrote:
>
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.
>
>>>>>
>
>>>>>
>
>>>>
>
>>
>