Just saw this on cafeaulait.org in today’s news about the latest 1.5 spec:
“Features dropped since the previous draft include a high resolution timer. Comments are due by June 10.”
The feature has been partially implemented: the method System.nanoTime gives the elapsed time in nanoseconds since an arbitrary start point. The actual resolution should be the best available on the machine.
If they remove System.nanoTime(), I swear I will never program in Java ever again!
It hasn’t been removed — the latest version of the Tiger content document now mentions that this feature remains (although other parts of the high resolution timer request were lost).
[quote]It hasn’t been removed — the latest version of the Tiger content document now mentions that this feature remains (although other parts of the high resolution timer request were lost).
[/quote]
Oh. Is there any info on which parts “were lost” and why?
"In 0.42 Feature 4614021 Provide a high resolution timer in j2se was dropped, however a small subset of that original request has been implemented as part of JSR 166 as System.nanoTime as noted in bug 4478186. "
Maybe check the bug database for bug # 4614021 to see what we won’t get.
Original RFE asked for accurate replacement for System.currentTimeMillis - this means nanotimer with value which means something as absolute number. Instead we ‘only’ get a nanoTimer which makes sense as relative value (but you cannot use it for detecting wall clock time). This means we get everything we need for games, so no reason to worry.
Just wondering, does the nano timer ever “wrap around” when it reaches a certain value?
[quote]Just wondering, does the nano timer ever “wrap around” when it reaches a certain value?
[/quote]
Yes, I guess so… but it doesn’t matter, because it just won’t happen in your whole life (or in this millenium) :>
long is -9,2210^18 to 9,22310^18 do the math if you want the accurate values 
sigh
It’s a small change and certainly one we can live with, but I have to wonder what’s so hard about the original design that made it impossible to implement?
Edit: By the way, I think a long-based nanosecond timer should run out in 285 thousand years, give or take a millienia or two?
Ah…isn’t the problem though that it isn’t necessarily started at 0? If it’s “only correct for relative time” it could theoretically start initialized at any value - and that could force you to do wrap-around handling (and get some horribly hard to reproduce bugs!).
Docs are useful:
[quote]Differences in successive calls that span greater than approximately 292 years (263 nanoseconds) will not accurately compute elapsed time due to numerical overflow.
[/quote]
Wrap-around handling is not required, because you will get the correct difference between two long values, even if one or both exceed the maximum value of long variables.