Thread.sleep() implementation

Do you know any other reasons for not using timed wait in Thread.sleep() implementation?

Because the native thread libraries provide a perfectly good sleep function: http://www.gnu.org/software/libc/manual/html_node/Sleeping.html

To understand why native threads are important, start at http://java.sun.com/docs/hotspot/threads/threads.html

Version 1.1 is based on green threads and won't be covered here. Green threads are simulated threads within the VM and were used prior to going to a native OS threading model in 1.2 and beyond. Green threads may have had an advantage on Linux at one point (since you don't have to spawn a process for each native thread), but VM technology has advanced significantly since version 1.1 and any benefit green threads had in the past is erased by the performance increases over the years.

Thread.sleep() will not be woken up early by spurious wakeups. If using Object.wait(), to do it properly (i.e. ensure you wait enough time) you would need a loop with a query to elapsed time (such as System.currentTimeMillis()) to make sure you wait enough.

Technically you could achieve the same functionality of Thread.sleep() with Object.wait() but you would need to write more code do it correctly.

This is also a relevant and useful discussion.

One could easily say Occam's Razor cuts the other way. The normal/expected implementation of the JVM underlying JDK is assumed to bind java 'threads' onto native threads most of the time, and putting a thread to sleep is a fundamental function of the underlying platform. Why reimplement it in java if thread code is going to be native anyway? The simplest solution is use the function that's already there.

Some other considerations: Uncontested synchronization is negligible in modern JVMs, but this wasn't always so. It used to be a fairly "expensive" operation to acquire that object monitor.

If you implement thread sleeping inside java code, and the way you implement it does not also bind to a native thread wait, the operating system has to keep scheduling that thread in order to run the code that checks if it's time to wake up. As hashed out in the comments, this would obviously not be true for your example on a modern JVM, but it's tough to say 1) what may have been in place and expected at the time the Thread class was first specified that way. and 2) If that assertion works for every platform one may have ever wanted to implement a JVM on.