Skip to main content

[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 16:20:47 +0200

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