Why in java.lang.Object?

Hi ppl,
I have a question which was asked in an interview.

java.lang.Object [superclass of any object] does have 3 methods related to threads, namely
(a) wait()
(b) notify()
(c) notifyAll().

The question was,"Why these threads related methods are present in Object class rather than in java.lang.Thread class?".

Can you please give a suitable answer?

Thanks,
Raghavan alias Saravanan M.

because the language designers chose to put them there...

You notify something waiting on a thread, not the thread itself.
Same with waiting, you wait for some object to become free, not on a thread to release a lock per se.

Etc. etc.

second guessing language designers is a waste of time, unless you're a language designer of at least equal experience yourself.

Think for a moment about what those methods do. Let's just look at one of them - wait(). This method causes the current thread to stop processing until some other thread invokes notify() or notifyAll() and it can resume processing. So, this method really only makes sense in a multi-threaded environment.

Now, think about how we can create new threads. You can extend the Thread class or you can create a class that implements Runnable. And let's not forget that your entry method (main) is going to be executed by a thread. So you might want to invoke wait() from a class that extends Thread, from a class that implements Runnable, or from a class that does neither. So where can the methods wait, notify, and notifyAll go such that all three of these cases will have access to them? java.lang.Object.
[ April 26, 2006: Message edited by: Corey McGlone ]

Some teams have a "build token" like a toy monkey that you have to have in hand before you can check in code. If you want to check in, you go get the token off its hook on the wall. If it's not there, you wait until the token is back on its hook. You don't know who has it so you can't wait on them. You just watch the hook.

Same with these methods. You use some object as the hook, and the thread monitor as the token. You don't know what thread has the monitor so you can't call a method on that thread to wait. And calling a method on your own thread wouldn't help because it doesn't have the monitor. You just wait until the other thread gives up the monitor and puts the token back on the hook.

Thanks a lot for Joreon, Corey and James!
The justification/reason was excellent.

Thanks,
Raghavan alias Saravanan M.

To clarify a bit what Cory said: In Java you're effectively ALWAYS working multithreaded (even if you may not notice).

Last night I was trying to see how far I could stretch this build token fable ...

When somebody puts the token back on the hook they ring a bell. You hear the bell and run over to get the token. There is a chance that somebody else will beat you to it and you'll have to wait again. That's why you often see a loop when Using the nofityAll and Wait Metods.