Use System.nanoTime() instead of System.currentTimeMillis() in StopWatch

[shenjianeng]

why does not StopWatch use System.nanoTime()

[bclozel]

We don't use the Spring Framework issue tracker for questions, but judging from your question it looks like you're considering that to be a bug.

Why should StopWatch be using nanotime? Could you explain the use case and why the current implementation is wrong?

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[spring-projects-issues]

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

[pcdavid]

I'm not the original reporter, but I just had the same remark/question when stumbling on the org.springframework.util.StopWatch implementation.

The Javadoc for currentTimeMillis() indicates:

Note that while the unit of time of the return value is a millisecond, the granularity of the value depends on the underlying operating system and may be larger. For example, many operating systems measure time in units of tens of milliseconds.

nanoTime() on the other hand is explicitly designed to measure precise time intervals between invocations (its absolute value however is meaningless). It is guaranteed to use a resolution at least as fine as currentTimeMillis(), and possibly much better.

So currentTimeMillis() answers "what time is it?" accurately, but with possibly a limited precision. nanoTime is more precise (though not necessarily to the nanosecond), but should only be used to measure time intervals. For the use case of a stop-watch, it seems nanoTime is better suited.

As additional data points:

• Guava's StopWatch implementation uses nanoTime (see com.google.common.base.Ticker.SYSTEM_TICKER).
• Apache Commons Lang's StopWatch too.