Why wait(), notify(), notifyAll() declared in Object class?

[Rituparna Duttagupta]

Hi friends,
why is it that wait(), notify(), notifyAll() methods have been declared in the Object class and not in the Thread class? Is it possible to call these methods on the main thread?

If we create a thread by a Runnable instance, then how could we access the methods of the Thread class?? can we import java.lang.Thread?

[Rob Spoor]

Rituparna Duttagupta wrote:Hi friends,
why is it that wait(), notify(), notifyAll() methods have been declared in the Object class and not in the Thread class? Is it possible to call these methods on the main thread?

Please SearchFirst. I this question has been asked quite a few times before.

If we create a thread by a Runnable instance, then how could we access the methods of the Thread class?? can we import java.lang.Thread?

Thread.currentThread() returns a reference to the (surprise surprise) current Thread.

[Jim Hoglund]

Rituparna: These behaviors correctly belong to Object because
it is objects that must be protected from unwanted changes. Java
allows you to lock any object, even:

Object lockObject = new Object();

Jim ...

[Henry Wong]

Jim Hoglund wrote:Rituparna: These behaviors correctly belong to Object because it is objects that must be protected from unwanted changes. Java allows you to lock any object

Here is an excerpt from another topic -- my response to whether the Object class or the Thread class is the correct place for these methods.

Henry Wong wrote:
As already mentioned, the reason these methods are part of the Object class, is because any object can be used for synchronization, and hence, any object should be able to be used for notification. Having these methods as part of the Object class is, of course, better than the Thread class, in this regard.

However, there is a flaw. The flaw being that there isn't necessary a one to one mapping between a mutex and its condition variable. And the Java (synchronization, wait, notify) design enforces this. Prior to Java 5, this mapping is removed by classes designed just for being a lock and condition variables. At Java 5, the Lock and Condition class were added to deal with this.

So... IMHO, the answer should be that neither answer is correct. The best design, in retrospect, should have been something done entirely using classes.

Henry

[Rituparna Duttagupta]

thank you all, i got my answer now.