Use Advanced Search to search the entire archive.
[jsr363-experts] Re: Contradiction between the spec and javadoc
- From: Martin Desruisseaux <
>
- To:
- Subject: [jsr363-experts] Re: Contradiction between the spec and javadoc
- Date: Mon, 15 Dec 2014 13:05:07 +0900
- Organization: Geomatys
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