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: 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
>
>>
>
>>
>
>