OSGi、Java ModularityおよびJigsaw

だから、昨日の朝の時点で、OSGiが何であるかさえ知りませんでした。OSGiは私が何度も何度も何度も作っていくのを見ていた流行語だったので、ついにそれをブラッシュアップするための時間を取っておきました。

それは実際にはかなりクールなもののように思われるので、私は（記録のために）私がOSGiに対していかなる点でも反抗的ではないこと、およびこれがいくつかの「OSGi-bashing」の質問ではないことを述べることから始めたいと思います。

結局のところ、OSGiは基本的にJava ModularityのJSR 277に対応しているようですがJAR、特定の状況で名前空間の解決やクラスローディングの問題につながる可能性のあるファイル仕様の欠陥が認識されています。OSGiは他にも多くの本当にクールなことを行いますが、私が確認できることから、それはその最大の魅力（またはその1つ）です。

私にとって-かなり新しい（数年後の）Java EE開発者として、私たちが2011年に現在Java 7の時代に生きており、これらのクラスローディングの問題が依然として存在していることは、本当に心を揺さぶられます。特に、1つのアプリケーションサーバーに何百ものJARがあり、それらの多くが互いに異なるバージョンに依存し、すべてが（多かれ少なかれ）同時に実行されているエンタープライズ環境では。

私の質問：

私がOSGiに関心があるのと同じくらい、そしてそれが私のプロジェクトに役立つかどうか、またそれが自分のプロジェクトに役立つかどうかを知りたいと思っているのと同じくらい、ただ座ってそのような大きなことを学ぶ時間はありません。少なくとも今。

では、これらの問題が発生した場合、OSGi以外の開発者は何をすべきでしょうか？どのようなJavaのいずれかの場合には（オラクル/日/ JCP）ソリューションは、現在、存在しますか？なぜジグソーパズルはJ7から切り取られたのですか？Jigsawが来年J8で実装されるコミュニティはどれほど確実ですか？Javaプラットフォームの一部ではありませんが、プロジェクトのJigsawを入手することは可能ですか？

私がここで尋ねているのは、パニック、陰謀、そして顔の組み合わせです。OSGiが何であるかがようやく理解できたので、ジグソーのようなものが実現するまでに20年以上かかり、それがリリースから缶詰にされた可能性があることを "理解"しません。それは基本的なようです。

また、開発者として、私のソリューションがOSGiではないことにも興味があります。

また、注：これは「純粋なプログラミング」タイプの質問ではないことを知っていますが、あなたの一部の人があなたの鼻を形から崩す前に、私はこの質問を故意に付けたと述べておきたいと思いますそう。それは、仲間のSOersを最大限に尊敬しているだけであり、私が毎日ここに潜んでいるのを見ている "ITの神々"からの建築レベルの答えを探しているからです。

しかし、SOの質問はいくつかのコードセグメントで裏付けられると絶対に主張する皆さんのために：

int x = 9;

（このOSGi / Jigsaw / classloader / namespace / JAR hell stuffに参加できる人に感謝します！）

まず、ジグソーの主な使用例はJRE自体をモジュール化することであることを理解してください。二次的な目標として、他のJavaライブラリやアプリケーションで使用できるモジュールシステムを提供します。

私の見解では、ジグソーのようなものはおそらくJREにのみ必要ですが、他のJavaライブラリまたはアプリで使用した場合に解決すると主張するよりもはるかに多くの問題が発生します。

JREは非常に困難で特殊なケースです。それは12年以上も前のものであり、依存サイクルと無意味な依存に悩まされている恐ろしい混乱です。同時に、約900万人の開発者とおそらく何十億もの実行中のシステムが使用しています。したがって、リファクタリングによって重大な変更が発生した場合、JREをリファクタリングすることは絶対にできません。

OSGiは、モジュール式のソフトウェアを作成する（または強制する）ためのモジュールシステムです。既存の非モジュール式コードベースの上に単純にモジュール性を振りかけることはできません。非モジュール式のコードベースをモジュール式のコードベースにするには、必然的にいくつかのリファクタリングが必要です。クラスを適切なパッケージに移動したり、直接インスタンス化を分離されたサービスの使用に置き換えたりするなどです。

これにより、OSGiをJREコードベースに直接適用することが難しくなりますが、JREの個別のバージョンまたは「モジュール」にJREを分割して、JREの削減バージョンを配信できるようにする必要があります。

したがって、私はJigsawを、JREコードを分割しながら存続させる一種の「極端な手段」と見なしています。それはコードをよりモジュール化するのに役立ちません、そしてそれが実際にそれを使用するあらゆるライブラリやアプリケーションを進化させるために必要なメンテナンスを増加させると私は確信しています。

最後に、ジグソーはまだ存在せず、決して存在しない可能性があるのに対して、OSGiが存在します。OSGiコミュニティは、モジュール式アプリケーションの開発において12年の経験があります。モジュール式アプリケーションの開発に真剣に関心がある場合、OSGiは町で唯一のゲームです。

それは簡単です。もしあなたが今日Javaで実際のコンポーネントベースの開発をしたいなら、OSGiは町で唯一のゲームです。

私の意見では、JigsawはJDKで実行可能なことの妥協と、SUNとOSGiの連中との以前の悪い関係の組み合わせです。多分それはJava 8に同梱されるでしょうが、私たちは待つ必要があります。

典型的なエンタープライズ環境で作業している場合、OSGiは万能ではありません。クラスの可視性に関するいくつかのよく知られたライブラリー（Hibernateを見ている）が、もはや有効ではないクラスの可視性について想定しているため、クラスのロードがどのように機能するかを理解する必要があります。 OSGi内。

OSGiは好きですが、既存のシステムに改造しようとはしません。また、グリーンフィールド開発の点で長所と短所を比較検討します。OSGiのライフを単純化するApacheまたはEclipse製品を検討することをお勧めします。

OSGiを実行していない場合、同じライブラリの異なるバージョンに依存しているシステムを思い付いた場合は運が悪かります-できることは、複数のバージョンのライブラリは、私にとって「匂い」のようなアーキテクチャです。

現在の状況を説明するために「コーナーケース」というフレーズを使用するのが好きです。

JARファイルの仕様には欠点があり、特定のまれなケースで名前空間の解決とクラスローディングの問題につながる可能性があります

とにかく、何年もの間、私は、コードなしでの結果よりもクリーンで、分離され、一貫性があり、より保守可能なコードの作成をサポートし、さらに強化するツールとテクニックに興味を持っていました。テスト駆動設計とJunitはそのような組み合わせでした。

数か月かけてコードベースの大部分をOSGiに移行した後、OSGiはこの点でさらに優れたツールと言えます。そしてそれこそが、OSGiに移行する十分な理由です。長期的にはそれはあなたに多くのお金を節約します。

そしてボーナスとして、それはあなたにたくさんのクールなことをする機会を与えるでしょう。デモ中に、OAuthをサポートするために認証モジュールをシームレスにアップグレードしてトラフィックを失うことを想像してみてください...ものを作成することは突然再び喜びです！