Win a copy of Bad Programming Practices 101 (e-book) this week in the Beginning Java forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

wait() wait(long) wait(long, int) notify() and notifyAll()  RSS feed

 
Marshal
Posts: 59392
187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We all know those are five of the nine public methods of Object. Are they still in common use? Haven't they been superseded by methods like Condition#await(), signal(), and signalAll()? Do the low‑level methods from Object still feature in the exam?
 
author
Sheriff
Posts: 23553
138
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I don't know about the exam part of this question, but the Condition class is used in conjunction with the ReentrantLock class. Those methods of the Object class, are still needed to provide the condition variable support, when used with the synchronization keyword form of locking.

Henry
 
Campbell Ritchie
Marshal
Posts: 59392
187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you. The book did show threads acquiring locks with synchronized before calling wait().
 
Saloon Keeper
Posts: 8975
168
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't know about the exam, but in my opinion putting those methods in Object was a mistake and I'm happy that people are moving to the high level concurrency classes. I see lots of beginning programmers still use them though.

As far as I'm concerned, the only method that REALLY has any business being declared by Object is the getClass() method.

  • equals(Object) and hashCode() should have been part of an Equatable<T> interface, with equals() accepting T.
  • toString() should have been part of a Writable interface. String concatenation works on Writable objects. To concatenate an Object, first use Objects.toString().
  • finalize() is already deprecated.
  • The notify() and wait() methods are superseded by conditions, latches, barriers, etc. These classes must be implemented natively, instead of through the wait() and notify() methods.
  • clone() should have been replaced by a keyword that performs the cloning magic, and can only be used on special cloneable types that must have copy constructors, e.g.:






  •  
    Stephan van Hulst
    Saloon Keeper
    Posts: 8975
    168
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Maybe another method that could have been part of Object is the Class.cast(Object) method, as Object.castTo(Class<T>).
     
    Campbell Ritchie
    Marshal
    Posts: 59392
    187
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Stephan van Hulst wrote:. . . I'm happy that people are moving to the high level concurrency

    The book in question discusses the Object methods and synchronized, not the higher‑level methods, which suggests to me that the low‑level methods are asked about for the exam.

    . . .

  • equals(Object) and hashCode() should have been part of an Equatable<T> interface, with equals() accepting T.
  • . . .

    In which case Collections would have add(Equatable) methods rather than add(Object). And they really should have implemented generics from the word go, so it would always have been Equatable<T>.

  • clone() should have been replaced by a keyword . . .
  • . . . or as Joshua Bloch suggests it should have been in the Cloneable interface.
    And there could have been a serializable keyword as a counterpart to transient.
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 8975
    168
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Instead of adding a clone keyword, you could move the clone() method from Object to Cloneable, but I would prohibit the direct implementation of the Cloneable interface, much like you can't directly extend Enum. Instead, the cloneable keyword would make your class automatically implement Cloneable by making a copy of the block of memory that constitutes the original object and then calling the copy constructor.

    Serializable on the other hand is truly useless. It implies that there is only one way to serialize an object. Instead, you can serialize an object in many ways. The responsibility lies with the service that does the serializing, not the object itself.
     
    I have a knack for fixing things like this ... um ... sorry ... here is a consilitory tiny ad:
    Why should you try IntelliJ IDEA ?
    https://coderanch.com/wiki/696337/IntelliJ-IDEA
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!