That is exactly what my little DLL does, and it uses timeGetTime() to get the actual time. The dudes at Sun can do exactly the same as I do; I guess the reason they (still) have the old quirky timing code in their Windoze implementation is that the high resolution timing was supposedly not available on all Windoze versions (95 perhaps?), but I don't even think the latest JVMs run on those old versions anymore, so they COULD theoretically change the implementation now to fix it...
But then another evil that they really take seriously to the limit of sanity rears its ugly head: BACKWARDS COMPATIBILITY. They will not change the way a method, that is so widely used and has been present from the first horribly inefficient implementation of Java, behaves. Period. I have to agree with such policy from a business application perspective, but for multiplatform gaming (or other time critical application) purposes it sucks
But heck, the workaround is so easy anyway, why bring out the pitchforks and torches?