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 17:31:36 +0000
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.
>
>>>
>
>>>
>
>>
>