回答:
何故ですか？オブザーバーパターンを実装する必要がないということですか？
最初に後半に答える-
YES、それはあなたが実装するべきではありませんどういう意味ObserverとObervableもうね。
アプリケーションに十分な機能を備えたイベントモデルを提供していませんでした。たとえば、何かが変更されたという概念だけをサポートすることができましたが、何が変更されたかについての情報を伝えることはできませんでした。
アレックスの答えはそれをObserver弱くするObservableことをうまく前に置いています：すべてのは同じです。instanceofオブジェクトに基づくロジックを実装し、オブジェクトを具象型にObservable.update()メソッドにキャストする必要があります。
これに追加するには、Observableクラスをシリアル化できないなどのバグがありましたSerializable。インターフェイスを実装しておらず、そのメンバーはすべてプライベートだったためです。
その代わりのより良いものは何ですか？
一方Listeners、多くの型があり、それらにはコールバックメソッドがあり、キャストを必要としません。@Raviの回答で指摘されているように、PropertyChangeListener代わりに利用できます 。
それ以外の部分については@Deprecation、他の回答にもリンクされている他のパッケージを探索するための適切なドキュメントが付いています。
このメールに記載されているように、非推奨にも分析が付いていることに注意してください -
最近、これらに遭遇した人は、おそらく、
RxJavaまたは他のリアクティブストリームフレームワークを使用しているときに、誤ってそれらにヒットしています。その場合、ユーザーは通常、代わりにjdk9java.util.concurrent.FlowAPIを使用することを望み ます。これは、すべてのリアクティブストリームフレームワークが、今後予定されているjdk9互換バージョン内で互換性/相互運用可能でなければならないということです。
編集：APIの非推奨は主に上記の理由だけではなく、いくつかのバグレポート（上記にリンク）のコメントで言及されているようなレガシーコードを維持できないことにも言及する価値があります。何らかの方法でその実装の改善をマークします。
Listenerオブザーバーでもあります。
はい、Java 9では非推奨です。また、オブザーバーパターンを実装できなくなりました。
さらに理由があります：
シリアル化不可 -以来、ObservableはSerializableを実装していません。したがって、Observableとそのサブクラスをシリアル化することはできません。
スレッドセーフなし -メソッドはそのサブクラスによってオーバーライドでき、イベント通知はさまざまな順序で、場合によってはさまざまなスレッドで発生する可能性があり、「スレッドセーフティ」を混乱させるのに十分です。
あまり提供しない -
これらは、アプリケーションに十分な機能を備えたイベントモデルを提供していません。たとえば、何かが変更されたという概念のみをサポートしますが、何が変更されたかについての情報を伝えません。
未解決の問題 -言及したように、発生した多くの主要な問題（スレッドセーフティ、シリアル化可能）があり、それらのほとんどは修正が複雑で、まだ「修正されていない」か、アクティブな開発がありませんでした。そのため、この問題は非推奨になりました。
また、この回答を読むことをお勧めします。、@ Jeffは非推奨のその他の理由を説明しています。
あなたは使用することができるPropertyChangeEventとPropertyChangeListenerのjava.beansパッケージ。
PropertyChangeListenerを置き換えますがObserver、代わりに何を拡張/実装する必要がありObservableますか？
PropertyChangeSupportインスタンス変数として追加することだと思いますが、確認をお願いします。
ObserverがJava 9で廃止されたのはなぜですか？
回答：ObservableクラスとObserverイベントモデルがでサポートされているので、インターフェースは、Java 9で廃止されているObserverとObservable、非常に限られている、で配信通知の順序がObservable指定されていない、と状態の変更が通知と1対1に対応していません。
Javaドキュメントhttps://docs.oracle.com/javase/9/docs/api/java/util/Observable.htmlを参照してください
オブザーバーパターンの代替？
Observerの設計パターンには多くの選択肢があり、Reactive Streamsもその1つです。
リアクティブストリームまたはフローAPI：
FlowクラスのJava 9に導入し、4つの相互にインターフェイスを有している：Processor、Publisher、SubscriberおよびSubscription。
Flow.Processor ：サブスクライバーとパブリッシャーの両方として機能するコンポーネント。
Flow.Publisher ：サブスクライバーが受け取ったアイテムのプロデューサー。
Flow.Subscriber ：メッセージの受信者。
Flow.Subscription：Flow.PublisherとをリンクするメッセージコントロールFlow.Subscriber。
Javaドキュメントを参照してくださいhttps://docs.oracle.com/javase/9/docs/api/java/util/concurrent/Flow.html
Java 9以降、ObservableクラスとObserverインターフェースが廃止されたことを考慮してください。投稿のとおり、JavaのObserverとObservableはJDK 9で廃止されました
ObserverとObservableでサポートされるイベントモデルは非常に制限されており、Observableによって配信される通知の順序は指定されておらず、状態の変化は通知と1対1で対応していません。よりリッチなイベントモデルについては、
java.beansパッケージの使用を検討してください。スレッド間で信頼性の高い順序付けられたメッセージングを行うには、java.util.concurrentパッケージ内の同時データ構造の1つを使用することを検討して ください。リアクティブストリームスタイルのプログラミングについては、Flow APIをご覧ください。