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 13:51:13 +0000

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