Use Advanced Search to search the entire archive.
[jsr363-experts] Re: Should JSR-363 API provide the SI class?
- From: Werner Keil <
>
- To:
- Subject: [jsr363-experts] Re: Should JSR-363 API provide the SI class?
- Date: Sun, 14 Dec 2014 11:59:52 +0100
Well right now SI extends AbstractSystemOfUnits because it IS a
SystemOfUnit and therefore naturally implements it.
Hence it is part of the RI.
Other implementations may use say a NoSQL db, etc. So keeping the abstract
base class in implementations is reasonable, but pulling just one
implementing class out of that hierarchy sounds comtradicting.
IMHO if SI went into API (so we find a way to solve all the RI dependencies
in it;-) so should AbstractSystemOfUnits. It does not force every
implementor to use it. See AbstractMap, etc. in the JDK it's just a common
default option.
Werner
Am 14.12.2014 04:29 schrieb "Martin Desruisseaux" <
>:
>
Le 14/12/14 01:37, Werner Keil a écrit :
>
> Exposing SI in the API was a tempting thought, but a significant
>
> mix-up between API and RI in JSR 275 did us no good as you remember;-)
>
>
One problem with JSR-275, in my opinion, was that it exposed too much
>
implementation details. But SI constants for units defined by BIPM is
>
not an implementation details.
>
>
>
> We discussed moving abstract base classes, especially
>
> AbstractSystemOfUnits into the API (...snip...),
>
> see https://java.net/jira/browse/UNITSOFMEASUREMENT-42
>
>
I agree with the comments posted in the JIRA task: AbstractSystemOfUnits
>
should stay on the implementation side. There is no guarantees that an
>
other implementation would not use an other abstract base class. But
>
this is unrelated to the SI discussion - there is no need for those
>
classes for providing SI constants.
>
>
>
> If we wanted to provide any implementation class as "default" in the
>
> API, we would have to reopen this ticket first.
>
>
Not necessarily - using ServiceLoader in the static class initializer, a
>
SI class would not need to know the actual implementation classes.
>
>
>
Martin
>
>