2

主観的な質問である可能性が高いです。動作をカスタマイズするためにサードパーティ API のサブクラスを作成したかったのですが、API クラスのメソッドの 1 つにデフォルトのアクセス指定子があり、サブクラスが同じパッケージにないためオーバーライドできないという問題があります。 .

ただし、解決策が必要な場合は、サブクラスを API クラスと同じパッケージに配置し、デフォルトのアクセス指定子を持つメソッドを拡張できます。サードパーティの jar ファイルは、寛容な X11 タイプのライセンス (MIT ライセンスに似ています) の下でライセンスされています。

以下のクエリに対する回答を探しています

  1. サードパーティの jar (別の jar ファイル) の外部にサブクラスを作成することは合法ですが、同様のパッケージ変換を維持しますか?

  2. このアプローチに関する既知の問題 (同じパッケージ名であっても、2 つの jar ファイルに保存しました)(スタンドアロンの単体テストでテストしたところです)

  3. このようなシナリオでアプリ サーバーのクラス ローダーがどのように動作するか (どの jar ファイルが最初に読み込まれるか)

ライセンスに関連する私のクエリ(1)がここに当てはまらない場合はお詫びします。

前もって感謝します。

4

2 に答える 2

1

  1. これについて十分な知識がないため、最初の質問に答えることができません:)

  2. クラスローダーに依存します。通常、最初に検出されたクラスがロードされます。2番目は省略されます。ここでは、クラスローダーの解決順序に依存しません。確実なのは、リソースがクラスパスから読み取られることだけです。したがって、クラスパスが c:\a;c:\b で、同じ名前とパッケージを持つ 2 つのファイルがある場合、「a」にあるファイルが最初にロードされます。

  3. アプリケーション サーバー内のクラスローダーは、通常、特定のサーバーのベンダーによって実装されます。たとえば、戦争は通常、カスタムクラスローダー、つまり戦争ごとに異なるクラスローダーでロードされます。耳についても同様です。クラスローダは通常、アプリケーション サーバー内の階層を構成します。

そのため、技術的には機能したとしても、将来的に多くの頭痛の種になる可能性があります.

オープン ソース プロジェクトの場合は、パッチをオープン ソース コミュニティに提出するか、独自のバージョンをコンパイルする (ライセンスで許可されている場合) のが最善だと思います。

お役に立てれば

于 2012-10-29T07:35:47.950 に答える
1

(1) の場合: X11 ライセンスは、基本的に、作成者にクレジットを表示し、保証違反で訴えない限り、ソフトウェアで何でもできると述べています。あなたの提案に違法性はありません。

あなたが提案したことはうまくいくはずですが、それはハックです。問題は、サードパーティのライブラリが API の一部に対して過度に厳密なアクセス仕様を使用していることです。最良の方法は、オープンソース プロジェクトにパッチを提出することです。

パッチでは、問題のメソッドを package-private の代わりに単純に指定する必要があります。これにより、サブクラス (およびpackage-private アクセスが含まれprotectedているため、ライブラリのパッケージ内の他のクラス) から呼び出すことができます。protectedそうすれば、ライブラリの他のユーザーがクラスを拡張するのにも役立ちます。

于 2012-10-29T07:28:33.413 に答える