Menu
Observer pattern is used when there is one-to-many relationship between objects such as if one object is modified, its depenedent objects are to be notified automatically. Observer pattern falls under behavioral pattern category.
Implementation With Observer The java. util. Observer interface defines the update() method, so there's no need to define it ourselves as we did in the previous section. Here, the second argument comes from Observable as we'll see below.
The Java language supports the MVC architecture with two classes: Observer : Any object that wishes to be notified when the state of another object changes. Observable : Any object whose state may be of interest, and in whom another object may register an interest.
Observer is a behavioral design pattern that allows some objects to notify other objects about changes in their state. The Observer pattern provides a way to subscribe and unsubscribe to and from these events for any object that implements a subscriber interface.
Why is that? Does it mean that we shouldn't implement observer pattern anymore?
Answering the latter part first -
YES, it does mean you shouldn't implement Observer and Obervables anymore.
Why were they deprecated -
They didn't provide a rich enough event model for applications. For example, they could support only the notion that something has changed, but didn't convey any information about what has changed.
Alex's answer puts it nicely upfront that Observer has a weakness: all Observables are the same. You have to implement the logic that is based on instanceof and cast object to concrete type into Observable.update() method.
To add to it there were bugs like one could not serialize the Observable class because as it didn't implement Serializable interface and all of its members were private.
What is a better alternative to that?
On the other hand Listeners have a lot of types and they have callback methods and don't require casting. As pointed by @Ravi in his answer you can make use of PropertyChangeListener instead.
For the rest of it the @Deprecation has been marked with proper documentation to explore other packages as linked in other answers as well.
Note that the deprecation was also marked with an analysis as stated in this mail -
These days, anyone encountering these is probably hitting them by mistake while using
RxJavaor other reactive-stream frameworks. In which case, users will normally want to instead use the jdk9java.util.concurrent.FlowAPIs that all reactive-streams frameworks should be compatible/interoperable within their planned upcoming jdk9-compatible versions.
Edit: It's also worth mentioning that the deprecation of the APIs is not primarily just because of the above reason, but also being unable to maintain such legacy code as mentioned in comments of a few of the bug reports (linked above) which were raised to mark an improvement in its implementation in one or another way.
There are more reasons :
Not Serializable - Since, Observable doesn't implements Serializable. So, you can't Serialize Observable neither its subclass.
No Thread Safety - The methods can be overridden by its subclasses, and event notification can occur in different orders and possibly on different threads, which is enough to disrupt any "thread safety".
Less to offer -
They don't provide a rich enough event model for applications. For example, they support only the notion that something has changed, but they don't convey any information about what has changed
Open Issues - As mentioned, there were lot of major issues raised (thread safety, Serializable) and most of them had complexities to fix and still "not fixed" or No Active Development, and that is the reason why it has been deprecated.
I would also recommend to read this answer Why should the observer pattern be deprecated?, @Jeff has explained other reasons for deprecation.
You can use PropertyChangeEvent and PropertyChangeListener from java.beans package.
Why Observer is deprecated in Java 9?
Ans: The Observable class and the Observer interface have been deprecated in Java 9 because the event model supported by Observer and Observable is quite limited, the order of notifications delivered by Observable is unspecified, and state changes are not in one-for-one correspondence with notifications.
See Java doc https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html
Alternate of Observer pattern?
There are many alternatives of Observer design pattern and Reactive Streams is one of them.
Reactive Streams or Flow API:
Flow is a class introduced in Java 9 and has 4 interrelated interfaces : Processor, Publisher, Subscriber and Subscription.
Flow.Processor : A component that acts as both a Subscriber and Publisher.
Flow.Publisher : A producer of items received by Subscribers.
Flow.Subscriber : A receiver of messages.
Flow.Subscription: Message control linking a Flow.Publisher and Flow.Subscriber.
See Java doc https://docs.oracle.com/javase/9/docs/api/java/util/concurrent/Flow.html
Considering that the Observable class and the Observer interface have been deprecated as of Java 9. As per the post Java's Observer and Observable Are Deprecated in JDK 9
The event model supported by Observer and Observable is quite limited, the order of notifications delivered by Observable is unspecified, and state changes are not in one-for-one correspondence with notifications. For a richer event model, consider using the
java.beanspackage. For reliable and ordered messaging among threads, consider using one of the concurrent data structures in thejava.util.concurrentpackage. For reactive streams style programming, see the Flow API.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With