Skip to main content

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


[jsr363-experts] Contradiction between the spec and javadoc

Martin Desruisseaux 12/14/2014

[jsr363-experts] Re: Contradiction between the spec and javadoc

Werner Keil 12/14/2014

[jsr363-experts] Re: Contradiction between the spec and javadoc

Martin Desruisseaux 12/15/2014

[jsr363-experts] Re: Contradiction between the spec and javadoc

Leonardo Lima 12/16/2014

[jsr363-experts] Re: Contradiction between the spec and javadoc

Martin Desruisseaux 12/16/2014

[jsr363-experts] Re: Contradiction between the spec and javadoc

Werner Keil 12/16/2014
 
 
Close
loading
Please Confirm
Close