Skip to main content

[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: Sat, 13 Dec 2014 18:29:58 +0100

P.s.: for the sake of convenience, could you please also publish the Parent
POM, see
http://jcenter.bintray.com/tec/uom/uom-parent/0.7/

(As soon as the "head" evolves, there's going to be 0.8-SNAPSHOT, but at
least on JCenter they only permit milestone builds)

The 0.7 release of the API should be on GeoAPI repo I assume. Now when
things change in a new sprint, the API will also increase to 0.8-SNAPSHOT.

Thanks,
Werner

On Sat, Dec 13, 2014 at 6:02 PM, Werner Keil 
< >
 wrote:
>
> Thanks, please do.
> The code is frozen as of yesterday. None of the items discusses are
> show-stoppers for the EDR, so they'll come as JIRA or discussion items just
> like any result of the  review.
> I am just about to bundle the ZIP archive in a similar way as JSR 354 did.
> With the exact license. Not only because it's a nice date, for the ultimate
> EDR version of the Spec PDF let's use December 14. The artifacts and Git
> tags were mostly created while it was still Dec 12 in the US;-)
>
> If there are any changes to the Google Doc by the end of tomorrow, they
> are incorporated.
> The actual publishing date by PMO may vary, e.g. 354 had its EDR1 on 22
> April 2013, but the JCP site only published it by May 1. Depending on the
> pace and payloyd, we'd also see it shortly before Christmas or no later
> than say Jan 1, right before the EC F2F (I have not heard about travel, but
> I trust Leonardo already got his flight so at least one maybe 2 Spec Leads
> should be there to present it;-)
>
> Werner
>
> On Sat, Dec 13, 2014 at 5:50 PM, Martin Desruisseaux <
>  >
>  wrote:
>>
>>  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 <
>>
>>  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

[jsr363-experts] Re: PI

Werner Keil 12/17/2014

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

Leonardo Lima 12/16/2014
 
 
Close
loading
Please Confirm
Close