Use Advanced Search to search the entire archive.
[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.
>
>>
>
>>
>
>