94

そのため、昨日の朝の時点では、OSGi が何であるかさえわかりませんでした。OSGiは、私が何度も何度も目にする流行語にすぎなかったので、ようやくそれをブラッシュアップするための時間を確保しました。

それは実際には非常にクールなもののように思えるので、(記録として) 私はいかなる点でも反 OSGi ではなく、これは「OSGi バッシング」の質問でもないことを述べることから始めたいと思います。

結局のところ、OSGi は - 基本的に - Java Modularity のJSR 277JARに対処したようです。これは、特定のまれなケースで名前空間の解決とクラスローディングの問題につながる可能性があるファイル仕様に欠点があることを認識しています。OSGi は他にも多くの非常に優れた機能を備えていますが、私が確認できる限り、それが OSGi の最大の魅力 (またはその 1 つ) です。

私にとって - かなり新しい (ここ数年) Java EE 開発者として、私たちが 2011 年にいて、現在 Java 7 の時代に生きていること、そしてこれらのクラスローディングの問題がまだ存在していることは、まったく気が遠くなるようなことです。特に、1 つのアプリ サーバーに何百もの JAR が存在し、それらの多くが互いの異なるバージョンに依存し、すべて (多かれ少なかれ) 同時に実行されるエンタープライズ環境では.

私の質問：

私は OSGi に興味を持っていますし、OSGi が自分のプロジェクトに役立つかどうかを知りたいと思っていますが、座ってそれほど大きなことを学ぶ時間はありません。少なくとも今は。

では、これらの問題が発生した場合、OSGi 以外の開発者はどうすればよいのでしょうか? 現在存在するJava (Oracle/Sun/JCP) ソリューションは? なぜジグソーはJ7からカットされたのですか? Jigsaw が来年 J8 に実装されるというコミュニティの確証はありますか? まだ Java プラットフォームの一部ではありませんが、あなたのプロジェクトにジグソーを入手することは可能ですか?

ここで私が求めているのは、パニック、陰謀、顔の手のひらの組み合わせだと思います。OSGiが何であるかをようやく理解した今、ジグソーのようなものが実現するのに20年以上かかった方法と、それがリリースからどのように缶詰にされた可能性があるかを「理解」していません。それは基本的なようです。

また、開発者として、OSGi を除いて、自分のソリューションが何であるかについても興味があります。

また、注：これが「純粋なプログラミング」タイプの質問ではないことはわかっていますが、鼻が曲がって形が崩れる前に、（記録のために）意図的にこの質問をしたことを述べたいと思いましたそれで。それは、私が仲間の SOer に最大限の敬意を払っているからです。毎日ここに潜んでいるのを目にする「IT の神々」から、アーキテクチャ レベルの答えを探しています。

ただし、SO の質問には何らかのコード セグメントを使用することを絶対に主張する人のために、次のように説明します。

int x = 9;

(この OSGi/Jigsaw/classloader/namespace/JAR 地獄のようなものについて検討できる人に感謝します!)

4

3 に答える 3

101

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

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

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

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

これにより、OSGiをJREコードベースに直接適用することは困難になりますが、JREの縮小バージョンを提供できるように、JREを個別の部分または「モジュール」に分割する必要があります。

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

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

于 2011-09-21T13:06:47.470 に答える
21

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

私の意見では、Jigsawは、JDKで実行可能なことの妥協と、SUNとOSGiの人々の間の以前の悪い関係の組み合わせです。Java 8に同梱されるかもしれませんが、待つ必要があります。

OSGiは、一般的なエンタープライズ環境で作業している場合は万能薬ではありません。多くの有名なライブラリ（Hibernateを見て）がクラスの可視性について仮定を行ったため、クラスの読み込みがどのように機能するかを理解する必要があります。 OSGi内。

私はOSGiが好きですが、既存のシステムに後付けしようとはしません。また、グリーンフィールド開発の観点から長所と短所を比較検討します。OSGiの生活を簡素化するApacheまたはEclipse製品を検討し、すべてを自分で行うのではないことをお勧めします。

OSGiを使用していない場合、同じライブラリの異なるバージョンに依存するシステムを思いついた場合は運が悪いです。複数のバージョンのライブラリが必要ですが、問題を回避することしかできません。ライブラリは、私にはアーキテクチャの「匂い」のように見えます。

于 2011-09-21T11:54:12.357 に答える
15

現在の状況を説明するための「コーナーケース」というフレーズの使用が気に入っています。

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

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

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

そして、おまけとして、たくさんのクールなことをするチャンスを与えてくれます。デモ中に、OAuth をサポートするために、トラフィックを失うことなく認証モジュールをシームレスにアップグレードすることを想像してみてください。

于 2011-09-21T20:27:15.600 に答える