Games for example might need to draw regularly updated frames on the screen. Drawing frames as fast as possible would mean chewing the CPU (or one core at least) and potentially wasting resources on the machine not to mention power, while perhaps drawing at a framerate way beyond anything necessary for smooth motion. A simple solution to this is to take the time of the previous frame, perform any updates and then calculate how long the sleep should be to hit exactly 50 frames per second.
But what happens if the user, or an automated part of the OS syncing time with a time server (standard on most modern operating systems now) changes the clock between frames while the program is sleeping?
System.currentTimeMillis in Java offers the standard time measurement of milliseconds since 1970, but changing the clock on the operating system will change the value of System.currentTimeMillis. When the program wakes up if this potential (but not easily knowable) change has occurred it may calculate that it has overslept or underslept hugely. In this example if we assume the clock has been adjusted back five minutes, then depending on how the timing is implemented the program may calculate that it needs to pause for 5 minutes (and maybe a few milliseconds) to reach the next frame. Suddenly and without explanation the app or game has paused and the user is left scratching their head.
JWrapper now provides a utility class to avoid this issue entirely by having a clock that still returns precision in milliseconds but is kept (as closely as possible) constant over any clock changes. This allows you to write timing code anywhere without having to worry about clock changes interfering with your code and introducing either long unexpected delays or periods of unexpectedly very high rates.
For more details check out the class javadoc in the JWrapper Utility APIs.