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