[9] RFR of 8069269: (spec) Defect in the System.nanoTime spec

[Martin Buchholz]

We have struggled for years with formatting for code samples.  If you want
to change it, get authoritative statement on how to do it with latest
javadoc, publish it somewhere, and change it everywhere.  Putting the
}</pre> on a line by itself did not produce the most readable output IIRC.

---

I don't see why switching t0 and t1 makes things more readable.
A real improvement might be: since one almost never compares two nanoTime
values against each other, compare against "timeout" instead of against
zero.  E.g.

long startTime = System.nanoTime();
...
long elapsedNanos = System.nanoTime() - startTime;
if (elapsedNanos < timeout) ...

using currently popular conventions in j.u.c.

On Fri, Jan 23, 2015 at 12:56 PM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> Please review at your convenience:
>
> Issue:  https://bugs.openjdk.java.net/browse/JDK-8069269
> Patch:  http://cr.openjdk.java.net/~bpb/8069269/webrev.00/
>
> The effective change is line 391 -> 393; the remainder is reformatting.
>
> Consider these hypothetical nanoTime values:
>
>         long t0 = Long.MAX_VALUE - 41;
>         long t1 = t0 + 42;
>
> Ignoring numerical overflow, the second value is mathematically equal to
> 2^63 which is greater than the first value.
>
> The results of the old and new comparison methodologies applied to the two
> long values are:
>
> old:
>
>         (t1 - t0) < 0: false
>         t1 < t0:         true
>
> new:
>
>         (t0 - t1) < 0: true
>         t0 < t1:         false
>
> This exhibits that the old documentation is incorrect regarding the
> methodology to be used when comparing two nanoTime values in the case of
> numerical overflow, and that the new documentation is accurate in this case.
>
> Thanks,
>
> Brian