Link Details

It's a good question. I think it's because "synchronize" is a language construct so it shouldn't depend on a library class or a marker interface.

They shouldn't be methods of the Thread class because threads use data objects (not the threads themselves) for their synchronization.

The only reason to have wait/notify/notifyAll methods on Object is to allow locking on a per-object basis.

If you think about *just* a communication mechanism between multiple threads, then it would have been enough to have special lock objects and have these methods on that instead of the general Object class.

How about an example of locking an object but without thread synchronization?

Assuming the question is directed to me,

I mean Java could have easily defined special Lock objects and defined wait/notify on it and could have said that, whenever you do thread synchronization (i.e. you are inside the monitor), you have to use these Lock objects. It would have worked except that we would be limited to always used these locks instead of locking on our own business objects.

Yes, that's the point: using such lock objects would still work. Then this leads us back to the original question of why use the base Object class instead of such special lock objects. My conjecture is to avoid having the language feature depending on the class library.

In my opinion wait/notify/notifyAll methods on Object is a design flaw.

If I recall correctly, even Brian Goetz admitted this in his Concurrency in Practice book.

In Netbeans or FindBugs static code analysis there is a special rule called "don't expose your locks". The truth is, you can't be really sure who and when calls Object.wat() or Object.notify() if it's available everywhere. So it's considered being a design flaw there.

On a side note, the "every single object has a monitor" design seriously imposes performance potential in any JVM implementation. The Azuls Systems JVM engineer admitted that it was a serious showstopper in achieving real-time performance guarantees.

Please focus on the title :-)
Its "Why wait and notify is on Object class in Java". So we are trying to figure out why these may have been done the way it is.

Most of the discussion is drifting towards "Why wait and notify SHOULD NOT on Object class in Java".