Yep, Agreed. Better to go with System.nanoTime(). Atleast we will avoid the problems in the machines where it supports monotonicness.
Regards, Uma ________________________________________ From: Ivan Kelly [iv...@apache.org] Sent: Thursday, July 05, 2012 8:14 PM To: bookkeeper-dev@zookeeper.apache.org Subject: Re: Reg System.currentTimeMillis usage in BookKeeper > I agree it is not good to change the system time on a running > process, still I'm thinking we can use System.nanoTime(), this will > be giving the JVM startup time and will helpful to withstand this > kind of minor accidents(as this came in the stat calculation > logic). Good idea. Could you open a JIRA for this. System.nanoTime() should be monotonic on most systems, whereas currentTimeMillis() is not guarenteed to be. Apparently, System.nanoTime() can be non monotonic if the OS doesn't support it, but in that case it falls back to currentTimeMillis anyhow. Performance wise, they seem very similar on linux. currentTimeMillis is a little quicker, but it's the difference between .66 microseconds and .7 microseconds. Not worth losing sleep over. 100m invokations of nanoTime : 71085070000ns 71085ms 100m invokations of currentTimeMillis : 66250899000ns 66250ms There's an interesting bug report that codes through the monotonicness issue. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6458294 -Ivan
