問題タブ [java-platform-module-system]

Sun は、 Jigsawの形式で JDK をモジュール化することに多大な努力を払っており、他の Java 開発者が選択するモジュール形式であるべきだとほのめかしています。これを使用している唯一の注目すべきプレーヤーは、NetBeans (および派生アプリケーション) です。

一方、業界は OSGi を中心に標準化を進めており、主要なアプリケーション ベンダーはすべてモジュール プラットフォームに基づいてランタイムを構築しており、Sun 自身の Glassfish も同様です。NetBeans 独自のモジュールの代わりに OSGi をモジュール システムとして使用するための NetBeans のポートもあります。Maven でさえ、OSGi ランタイムになるように取り組んでいます。

NIH、ライセンス、または別の理由ですか?

Project Jigsaw for Java 8（JDKをモジュール化するため）を考慮に入れると、「新しい」Swingフレームワークを考慮に入れることができますか？

対価とは：

• 誰かが実際にそれを書き直している
• JDKリリースに含める

モジュールをJDKに含めることができるので、Swingの新しいフレームワークを作成して、新しいアプリケーション開発者が使用できるように提供できますが、レガシーアプリケーションの場合は、現在のSwingフレームワークが含まれると思います。

新しいSwingを書き直して、それを新しいJDKに含めることは、Java 8のオプションでしょうか？（このタスクで考慮すべきあなたの意見と考慮事項は何ですか？）

そのため、昨日の朝の時点では、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 の質問には何らかのコード セグメントを使用することを絶対に主張する人のために、次のように説明します。

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

Java のパッケージ管理システムは、私にとって常にシンプルで効果的なものに思えました。JDK自体によって頻繁に使用されます。名前空間とモジュールの概念を模倣するためにこれを使用してきました。

Project Jigsaw (別名Java Platform Module System )は何を入力しようとしていますか?

公式サイトより：

このプロジェクトの目標は、Java SE プラットフォームの標準モジュール システムを設計および実装し、そのシステムをプラットフォーム自体および JDK に適用することです。

Java 8 with Project Jigsaw は、SDK にモジュール システムをもたらします。パッケージの一部（組み込み）であるため、良いことだと思います。OSGi もモジュール システムを提供しますが、コンテナーが必要です。しかし、それとは別に、それらの間の主な違いは何ですか。

OSGi を使用する場合、標準の JDK 8 リリースを使用して OSGi を実行できますか?

デフォルトの SDK にそのような機能が含まれている場合、OSGi は関連しますか? 私の理解では、OSGi と Jigsaw の両方を使用して、ser ベースのアプリ (サーブレットなど) だけでなく、通常のモジュラー Java アプリケーションを作成できますよね?

OSGi、Java Modularity、および Jigsawの質問に対する回答によると、おそらく JRE には Jigsaw モジュール システムが必要です。JRE で言うと、OP は Java で記述された IO、CORBA、RMI などの Java 標準ライブラリを意味すると思いますか、それとも対象となるこれらの基礎となるクラス ライブラリの実装ですか? Jigsaw プロジェクトのページを読むと、前者だと思います。後者の場合、Java コードを作成する他の Java 開発者にどのように役立つのでしょうか? クラス ライブラリは C/C++ で記述されています。誰でも明確にしてもらえますか？

これは OSGi 対ジグソーではありません。どちらを使用するかを本当に理解したいです。新しいアプリケーション (デスクトップであろうとサーバーであろうと) を作成する場合は、標準的な実装によって時代遅れにならず、放棄されたままになる可能性のあるテクノロジに基づいていたいと考えています。OSGi が時代遅れだと言っているわけではありません。私は OSGi が好きです。OSGi自体の将来の方向性は何か、全体像を見ています。

現在、デスクトップ アプリケーション用のプラグイン コンセプトを開発する可能性を評価しています。
調査中に、OSGI と Java Platform Module System (または Project Jigsaw) について知りました。
Java Platform Module System の仕様について少し混乱しています。

• Java プラットフォーム モジュール システムでは、モジュールをプラグインのように追加できますか?
  オプションのモジュールを宣言して、そのサービスにアクセスすることは可能ですか?

• モジュールが独自のクラスパスを持ち、アプリケーションの残りの部分から分離することは可能ですか?

• サードパーティのプログラマーが、既存のアプリケーションにシームレスに統合するプラグインを実装することは可能ですか?

誰かが仕様を理解するのを手伝ってくれたら、とても感謝しています。

このコメントに出くわしたとき、私はJunit-Lambda wikiの最近の変更を読んでいました。

ジグソーのモジュール化を検討すべきか?

[...] コア コードで Jigsaw を必要とするということは、JUnit が Android で動作しないことを意味します。

Jigsaw を Android に適用すると、正確には何が壊れるのだろうか?

jdk9 以降のライブラリは Android で動作しなくなりますか?

Android を念頭に置いて開発されたライブラリは、「ジグソー」コードで使用できますか?

これをグーグルで検索すると、あらゆる種類のアプリが表示されるため、役に立ちません。

Java 9 では、循環モジュールは許可されますか? いいえの場合、その理由は何ですか?