Use Advanced Search to search the entire archive.
[jsr363-experts] Re: Contradiction between the spec and javadoc
- From: Leonardo Lima <
>
- To: "
" <
>
- Subject: [jsr363-experts] Re: Contradiction between the spec and javadoc
- Date: Tue, 16 Dec 2014 08:06:33 -0200
"*no runtime overhead compared with an implementation not using Unit-API" *is
impossible to reach, I don't see how an implementation using objects will
be faster than one using only primitives (unless primitives started being
Objects in ME 8 and I didn't notice...).
So I believe that when using the API, we're trading a little performance
for a clear, less bug-prone code.
I think we need to at least change this goal to be "the smallest possible
overhead...", if such wording is allowed in a spec.
Regards,
Leonardo.
On Mon, Dec 15, 2014 at 2:05 AM, Martin Desruisseaux <
>
wrote:
>
>
Le 14/12/14 21:41, Werner Keil a écrit :
>
>
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.
>
>
This is my question. I'm not trying to do "what please me", I'm trying to
>
make the document compliant with the reality. So what is the current
>
reality of the Reference Implementation (RI)? Does it support fractional
>
power of units or not? If not, is it a planed feature or is it considered
>
unnecessary for RI internal working?
>
>
>
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.
>
>
Value type will not solve the problem - Quantity operations will always be
>
slower at least because of the check for the unit of measurement.
>
>
The "*Small or no runtime overhead compared with an implementation not
>
using Unit-API*" goal was introduced in JSR-275 at a time where I
>
proposed the following methods in UnitConverter (similar to
>
java.awt.geom.AffineTransform methods):
>
>
- void convert(double[] src, int srcOffset, double[] dst, int
>
dstOffset, int num);
>
- void convert(float[] src, int srcOffset, float[] dst, int dstOffset,
>
int num);
>
- etc.
>
>
Those methods were rejected - its okay, I understand they were considered
>
too complicated. But without them, the performance goal is hard to achieve
>
(invoking UnitConverter.convert(double) in a loop is much more expensive).
>
>
>
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;-)
>
>
If the API makes impossible to reach the performance goal, this is a
>
Spec/API concern. But maybe we can keep this discussion for a latter stage.
>
>
Martin
>
>