The granulatiry of System.currentTimeMillis() is far too course to be useful in
many situations on the Microsoft platforms

On Windows 2000 the granularity is 10ms
On NT the granulatiry is 10ms
On Windows 98 the granularity is 50ms

There are a number of customers/ISV's encountering this issue.

Customers are writing their own JNI code to overcome this shortcoming which
is leading to non-portable Java applications.

N/A

JVM_CurrentTimeMillis() call returns system time (long) in nanoseconds divided by 10k. It is as precise as it can be. The problem is different. Java does not guarantee real time execution. It means that threads can be suspended because of GC or to yield another thread. See Java Real Time API for more details on this.
In this case the System.currentTimeMillis() granularity may seems to look too big, but it has nothing to do with JVM_CurrentTimeMillis().

 xxxxx@xxxxx  2001-05-18

Yet another inaccurate evaluation by Sun:

>> JVM_CurrentTimeMillis() call returns system time
>> (long) in nanoseconds divided by 10k

No, it returns the system time (which is in units of 100 
nanoseconds) divided by 10,000.  Namely, it converts 
systems units to Java units (milliseconds).

>>It is as precise as it can be. The problem is different.

Absolutely true.  Java could return a time that is accurate 
to 1-ms to fit within the 1-ms precision capability of 
currentTimeMillis(), but instead chooses not to.  That is 
the problem.

>> Java does not guarantee real time execution. It
>> means that threads can be suspended because of
>> GC or to yield another thread. See Java Real
>> Time API for more details on this.

who cares? an excuse with no relevance to the problem 
description

>> In this case the System.currentTimeMillis()
>> granularity may seems to look too big, but
>> it has nothing to do with JVM_CurrentTimeMillis().

Very strange comment, given that the sources indicate 
otherwise.  In System.c, "currentTimeMillis" is mapped to 
JVM_CurrentTimeMillis, is it not?

I agree it is a strange evaluation, I wonder if this is the 
official Sun opinion. 
I would vote for re-opening this bug.

I would vote for it to!

me too, that's a real shame !
i use often this method to check the efficiency of many of
our framework  functions, a sub millisec granularity would
be a great help.
and for instance we cannot use the JNI  code as our dev,
test and prod platform is respectively Windows, Solaris and
AIX...

Please reopen..

currentTimeMillis() returns the time-of-day clock time and its resolution is determined by the OS. If you need finer resolution then use System.nanoTime in Java 5+.

For the more general issue of using clocks and timers on win32 please see my blog entry:
http://blogs.sun.com/dholmes/entry/inside_the_hotspot_vm_clocks

Fix - or if it's not possible to make a System.currentTimeMillis() that fufills all the requirements for compatibility, then add a new API for high preciscion timing.  

Just fix.

I see - System.nanoTime(), since 1.5