I was curious as to why a sleeper deamonized thread was needed to accomplish this, and found the following information about it:
To try and alleviate the low granularity, the VM actually makes a special call to set the interrupt period to 1ms while any Java thread is sleeping, if it requests a sleep interval that is not a multiple of 10ms. This means you are actually making a system-wide change to interrupt behavior (although generally not such a problem).
Generally, the solution works well enough, but: there is also a bug in Windows (XP, 2000, 2003) whereby repeatedly altering the interrupt period (and hence, repeatedly sleeping in Java for periods that are not multiples of 10ms)can make the system clock run faster than normal. Hotspot assumes that the default interrupt period is 10ms, but on some hardware it is 15ms.
If timing is crucial to your application, then an inelegant but practical way to get round these bugs is to leave a daemon thread running throughout the duration of your application that simply sleeps for a large prime number of milliseconds (Long.MAX_VALUE for example). This way, the interrupt period will be set once per invocation of your application, minimizing the effect on the system clock, and setting the sleep granularity to 1ms even where the default interrupt period isn't 15ms.
REFERENCES:
1)
http://javamex.com/tutorials/threads/sleep_issues.shtml2)
https://support.microsoft.com/en-us/help/821893/the-system-clock-may-run-fast-when-you-use-the-acpi-power-management-t