Oh gawd, I hope that doesn't make it in as final documentation - I didn't think it could get any worse than it is now, but...

292 years == 263 nanoseconds is clearly a typo (I hope!), but "not necessarily nanosecond accuracy...no guarantees are made about how frequently values change". Doesn't that mean it's completely useless? It may return a difference of 5 after 240 nanoseconds have elapsed (no guarantee, etc)?

It is about same useless as currentTimeMillis() as far as specificiation is concerned. It is just system dependent. What we can hope for, is that on most systems it will be implemented using high precision timers, as there are no technical reasons to not use them. And I think that they will just use same thing which was available in java3d, so I'm not afraid about the details.

I'm very happy to see the new system timer. I'm also very happy to see all of Doug Lea's multithreading library making it into Java. I've been using it for years now, but it really is the kind of thing that should have been a part of the core library since the beginning.

Differences in successive calls that span greater than approximately 292 years [...] will not accurately compute elapsed time due to numerical overflow.

Damn! My application needs to stay up for more that 300 years at a time. Where do I submit an RFE to get this fixed?

A long time ago, someone I worked with became concerned with a particular counter's potential to roll over and cause havoc with our system. I did a few calculations, and related the happy news that we were safe for the next 280 million years, or so...

Quote

[...] but "not necessarily nanosecond accuracy...no guarantees are made about how frequently values change". Doesn't that mean it's completely useless? It may return a difference of 5 after 240 nanoseconds have elapsed (no guarantee, etc)?

No worse than what we've already got. I'd still prefer a way of querying the timer's actual accuracy, if only for use as a guideline.

You can't create a bug, because it's just a JSR in public review. You can give your feedback on it there, although, I don't know how receptive they will be considering the JSR is on multi-threaded programming, and not system timers.

I asked the Spec lead about providing a method to query the resolution, here is his response:

Quote

We considered options along these lines, but none of them work outvery well. Among the problems are:

1. The update frequency need not be constant, including on someversions of Windows.

2. The returned value may be synthetic, as it is on mostmultiprocesors, that use ntp-like adjustments to keep processor clocksin sync, so there is no meaningful granularity to report.

3. The internal granularities governing delay/wait times (especiallyin JSR166 timeout methods) may be different than elapsed-timegranularities.

Of course, these kinds of problems can also hit you if you useinternal loops to estimate. In either case you are left with thebest-effort intent of nanoTime: It is the most precise timer availableon the platform.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org