Skip to main content

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


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

Werner Keil 04/07/2015

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

Chris Senior 04/08/2015

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

Werner Keil 04/08/2015

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

Chris Senior 04/08/2015

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

Werner Keil 04/08/2015

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

Leonardo Lima 04/20/2015
 
 
Close
loading
Please Confirm
Close