25

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

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

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

4

5 に答える 5

8

http://blogs.oracle.com/mr/entry/jigsawを引用:

OSGi は Java 言語とはまったく統合されていませんが、Java SE プラットフォーム内からではなく、その上に構築されています。

この最後の問題は修正できます。Sun は、OSGi Framework の将来のバージョンが JSR 294 の機能を完全に活用し、それによって言語とのより緊密な統合を実現できるように、OSGi Alliance と直接協力する予定です。

(...)

Java SE プラットフォームの将来のバージョンに特定のモジュール システムが含まれる場合、Sun は、Jigsaw モジュールをその標準に移行する手段を提供します。それまでの間、他のモジュール システム、特に OSGi と相互運用する方法を積極的に模索します。

于 2009-12-07T09:58:45.033 に答える
5

プロジェクト Jigsaw の背後にある理論的根拠と、それが OSGi とどのように関係しているかについては、Jigsaw チームによってJava Posse Podcast 259で概説されています。

これらのプロジェクトは完全に重複するわけではなく、Jigsaw の導入が OSGi の終焉の鐘を鳴らすことはありません。OSGi の範囲は、Jigsaw が試みるものを超えています。ジグソーには、OSGi チームが提供できる以上のものがあります (言語、クラス、および JVM 実装の変更)。OSGi の設計は、現在の JVM 設計に基づいています。JVM への変更は、すべての人に利益をもたらします。

少なくとも、それは私が読んだものからの私の見解です。

于 2009-12-07T10:37:51.743 に答える
4

素晴らしい質問です。私の理解では、ある領域では OSGi は JVM モジュールに必要なものをはるかに超えており (対応するすべての複雑さがもたらされます)、他の領域では十分ではありません。そのため、それらの間には多くの重複がありますが、おそらく十分ではありません.

このブログエントリを参照してください

于 2009-12-07T09:59:29.677 に答える
1

この件に関する Mark Reinholdの JavaPosseインタビューをご覧ください。

于 2009-12-10T19:26:36.283 に答える
1

OSGi には 1 つの機能がありません。パッケージのサブセットであるモジュールはサポートしていません。エクスポートはパッケージ レベルで行われます。

パッケージ サブセット モジュールは、JDK 依存関係のゴルディアン ノットを切り離す唯一の方法です。そして、コードを循環依存からきれいに保つ必要がある理由の良いヒントです。

しかし、このスタイルの開発では、API 間 (およびその実装間) に予期しない接続が発生し、起動時間とメモリ フットプリントが増加する可能性があります。簡単なコマンドライン「Hello, world!」たとえば、クラス データの共有などのさらに大胆なエンジニアリング作業にもかかわらず、最近のデスクトップ マシンでは約 100 ミリ秒かかります。もちろん、大規模なアプリケーションの場合、状況はさらに悪化します。

編集：私は間違っていました。OSGi は分割パッケージをサポートしています。

于 2009-12-07T10:07:27.870 に答える