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.

On the other hand Listeners have a lot of types and they have callback methods and doesn'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 RxJava or other reactive-stream frameworks. In
which case, users will normally want to instead use the jdk9
java.util.concurrent.Flow APIs that all reactive-streams frameworks
should be compatible/interoperable within their planned upcoming
jdk9-compatible versions.

Edit: Its 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 few of the bug reports(linked above) which were raised to mark an improvement in its implementaion in one or the other way.

+1. Good answer, though I am still trying to understand it. Is Observer in Java deprecated because of some inherent problem of the design pattern itself (as defined in the book by GOF) or the problem of the support for the pattern by Java? In other OO languages, such as C#, C++, Python, does the observer design pattern also have the same problem as in Java?
– TimSep 23 '17 at 21:31

15

The fact that a particular implementation is deprecated doesn't mean that the Observer pattern is fatally flawed. Listener is also an Observer.
– chrylisSep 24 '17 at 0:03

@chrylis Thanks, couldn' t agree more, one of the main reasons to deprecate the API is also the maintenance attached to it and that changing its implementation could have been breaking other code.
– nullpointerSep 24 '17 at 1:55

@nullpointer Was observers way of notifying concurrent?
– curious95Sep 24 '17 at 13:34

3

@curious95 Yes calling notifyObservers() is concurrent. Here is a codelet from the same shared to explain its functionality in details.
– nullpointerSep 24 '17 at 19:30

Why is that?

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".

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.

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.

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.beans
package. For reliable and ordered messaging among threads, consider
using one of the concurrent data structures in the
java.util.concurrent package. For reactive streams style programming, see the Flow API.