Use Advanced Search to search the entire archive.
[jsr363-experts] Re: Contradiction between the spec and javadoc
- From: Werner Keil <
>
- To: "
" <
>
- Subject: [jsr363-experts] Re: Contradiction between the spec and javadoc
- Date: Sun, 14 Dec 2014 13:41:58 +0100
As seen earlier, some of the spec has initial contributions as old as JSR
108.
If neither the current implementations contain such restriction nor do we
think it makes sense to add till the final version of the code, please feel
free to remove it from the spec.
The 0.7 tag is now frozen and JavaDoc improvements can always be done in
the next stage or iteration If you feel, that must be removed from the Unit
code, please raise a JIRA ticket first describing the problem, then
anybody who works on it can pick it up.
If you feel so uncomfortable wit the sentence, go ahead. I can't remember
if it came in with 275 or even before. Primitives are a dying breed for
Java or at least once "value types" are introduced, something like Integer
or Double likely will become value types. Whether or not they perform
better, we shall see.
If something performs good or bad after all is an implementation detail,
and even the RI does not necessarily claim to be the "most performant" one.
Other implementors are free to use JCache or whatever they want to improve
performance, but the Spec/API does not really care much about that;-)
Thanks,
Werner
On Sun, Dec 14, 2014 at 5:15 AM, Martin Desruisseaux <
>
wrote:
>
>
Page 9 of the specification, section "Aspirations", said:
>
>
- Support for fractional exponents, such as kg3/2. Fractional
>
exponents sometimes appear as a partial result on the way to a final
>
value.
>
>
while javadoc of Unit said "Units raised at non-integral powers are not
>
supported. For example, LITRE.root(2) raises an ArithmeticException".
>
Which one is true?
>
>
In addition, unless someone is willing to explain under which
>
circumstances the sentence may be true, I plan to remove the "Small or no
>
runtime overhead compared with an implementation not using Unit-API". Note
>
that I do not think that comparing to a String is appropriate, since
>
unless otherwise specified I think that a majority of developers would
>
expect a comparison with the double primitive type.
>
>
Martin
>
>