Skip to main content

[jsr363-experts] Re: Should JSR-363 API provide the SI class?

  • From: Martin Desruisseaux < >
  • To:
  • Subject: [jsr363-experts] Re: Should JSR-363 API provide the SI class?
  • Date: Sun, 14 Dec 2014 01:50:08 +0900
  • Organization: Geomatys

Just a quick note (I will continue to review the spec tomorrow). I have
no strong opinion about whether JSR-363 should provide the SI class or
not. I see pros and cons on both sides. It is just that the spec
mentions the SI classes in many places, so we have to choose between
either providing that class or removing its mentions from the spec (or
rephrase them in an other way).

    Martin


Le 14/12/14 01:37, Werner Keil a écrit :
> There are one or two examples, in one case I highlighted the fact,
> that a "constant" like CENTI or METRE are defined by RI types like SI.
> The API part of the spec can barely talk about units withoug
> mentioning a few examples. 
>
> 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;-)
> Certainly JSRs like 354 (I'm not talking about 310 since it is an even
> worse mix-up than what we had once and it even has API types that
> depends on RI classes;-O) use the Java SE service loader mechanism to
> allow a singleton convenience class like MonetaryAmounts to be in the API.
>
> We discussed moving abstract base classes, especially
> AbstractSystemOfUnits into the API (in it's case it would be an
> absolute no-brainer, there are neither Java SE specific types nor
> anything RI specific in that class) Last time we had a Hangout this
> idea was discarded or at least found to be not feasable at the time,
> see https://java.net/jira/browse/UNITSOFMEASUREMENT-42
>
> If we wanted to provide any implementation class as "default" in the
> API, we would have to reopen this ticket first.
> Unlike SystemOfUnits the constants in SI or other concrete systems
> refer to so many concrete unit classes like TransformedUnit, BaseUnit,
> etc. that it would be very hard.
> At the moment trying to declare all of these as Unit<Q> instead would
> cause a riple-effect making other declarations unusable. So a
> significant refactoring and rewrite of not just SI would be necessary
> and its abstract base class
> (https://java.net/jira/browse/UNITSOFMEASUREMENT-42) would first have
> to be moved, before concrete classes like SI could ever be.
>
> Regards,
> Werner
>
> On Sat, Dec 13, 2014 at 1:40 PM, Martin Desruisseaux
> <
> <mailto: >>
>  wrote:
>
>     The specification mentions in many places the SI class, which is not
>     part of the API (I guess it is available in the implementation).
>     Should
>     we add this class to JSR-363 API? Note that it does not
>     necessarily ties
>     the API to a specific implementation, since the SI class static
>     initializer could use the UnitProvider interface in the spi package
>     (using java.util.ServiceLoader for the discovery process).
>
>         Martin
>



[jsr363-experts] Should JSR-363 API provide the SI class?

Martin Desruisseaux 12/13/2014

[jsr363-experts] Re: Should JSR-363 API provide the SI class?

Werner Keil 12/13/2014

[jsr363-experts] Re: Should JSR-363 API provide the SI class?

Martin Desruisseaux 12/13/2014

[jsr363-experts] Re: Should JSR-363 API provide the SI class?

Werner Keil 12/13/2014

[jsr363-experts] Re: Should JSR-363 API provide the SI class?

Werner Keil 12/13/2014

[jsr363-experts] Re: Should JSR-363 API provide the SI class?

Martin Desruisseaux 12/14/2014

[jsr363-experts] Re: Should JSR-363 API provide the SI class?

Werner Keil 12/14/2014

[jsr363-experts] Re: Should JSR-363 API provide the SI class?

Martin Desruisseaux 12/14/2014

[jsr363-experts] Re: Should JSR-363 API provide the SI class?

Werner Keil 12/14/2014

[jsr363-experts] PI

Martin Desruisseaux 12/14/2014

[jsr363-experts] Re: PI

Werner Keil 12/14/2014

[jsr363-experts] Re: PI

Martin Desruisseaux 12/14/2014

[jsr363-experts] Re: PI

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