Skip to main content

Re: Question: javax.measure.quantity in API

  • From: Werner Keil < >
  • To:
  • Subject: Re: Question: javax.measure.quantity in API
  • Date: Wed, 13 Aug 2014 13:16:56 +0200

There is some point, e.g. I always insisted on those being "optional".
While acual unit systems like SI depend on concrete implementations,
(AbstractSystemOfUnits in theory could be added to API, see 354, it
contains no references to anything that is not available in CLDC8 or
implementation-specific references) those SI quantities are interfaces, too
and ensure the type-safe compatibility, e.g. that *Temperature *and
*Mass *cannot
be mixed up.

So they are more like annotations (e.g. the ones that could be defined on
top of JSR 308, but it wouldn't work at runtime nor anywhere other than
Java SE 8 or 9+) or similar "guiding" types, though one could also use them
as value holders (and the way e.g. a concrete TemperatureAmount not only
extends an Abstract RI/impl type like *BaseAmount*, *AbstractAmount*, etc.
but implements Temperature is legitimate and especially towards future
"value types" could easily be applied there, too. A value type shall be
able to implement interfaces, thus these interfaces can be used in future
Java versions, too)

Thus they are not just "extensions" of Quantity, but only Quantity is a
mandatory base interface. Hence the "quantity" package is separate from it,
but defining each of those in the RI, SE Implementation or others would
make "RI Mass" and "SE Mass" incompatible, thus the base types from the SI
system should be in a single place like "javax.measure". We are not forced
to put them into the same JAR, actually those if nothing else would be a
good case for a separate module, but we shold declare those as part of the
Spec/API to ensure compatibility not only on a method signature level, but
between different implementations if they use this optional package.

On a smaller scale, that's exactly what e.g. Google Fit does by defining a
set of data types like "google.fit.weight" or "google.fit.height", etc.
(those are targeting health/fitness and do not always properly represent SI
or other standard types[?]) but allowing other vendors to add their own
types (let's say "somevendor.fit.stairswalked") The
"somevendor.fit.stairswalked" and "someothervendor.fitness.stairswalked"
won't be compatible with each other, but the base types Google (or JSR 363
in this case) defined remain compatible across the platform.

HTH,
Werner


On Wed, Aug 13, 2014 at 12:33 PM, Otávio Gonçalves de Santana <
>
 wrote:

>
> In API I see some classes that are specialized of Quantity.
> Do these classes should not go to impl?
> I believe the API, should contain the behavior of Quantity and measure
> Unit and not the specializations, isn't?
>
> --
> Otávio Gonçalves de Santana
>
> blog:     http://otaviosantana.blogspot.com.br/
> twitter: http://twitter.com/otaviojava
> site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
> 55 (11) 98255-3513
>
>

Attachment: 329.gif
Description: GIF image



Question: javax.measure.quantity in API

Otávio Gonçalves de Santana 08/13/2014

Re: Question: javax.measure.quantity in API

Werner Keil 08/13/2014

Re: Question: javax.measure.quantity in API

Martin Desruisseaux 08/14/2014

Re: Question: javax.measure.quantity in API

Werner Keil 08/14/2014
 
 
Close
loading
Please Confirm
Close