3

ライブラリとしてパッケージ化されたクラスファイルにアクセスしようとしていますが、残念ながら、jarライブラリは別のjarファイルにパッケージ化する必要があります。

例として、いくつかのクラスライブラリを含むa.jarがあるとします。外部のJavaアプリケーションからjarファイルのクラスを呼び出す（インポートする）ことができます。次に、このa.jarをb.jarなどの別のjar内に配置し、b.jarの外部からa.jar内のクラスにアクセス（インポート）する必要があります。

これは私がやりたいことではありません:)

4

2 に答える 2

6

「jar内のjar」を処理できるクラスローダーを作成する必要があります。これは私にはかなり悪い考えのように聞こえます。

jarファイルをマージしないでください。ディスク上に別々に置いてください。より多くのファイルを用意する必要性について経営陣を説得する必要があるかもしれませんが、それによってすべてがはるかに簡単になります。クラスローダーの作成は簡単ではありません...

于 2009-08-11T06:19:58.560 に答える
1

正しく理解していないかもしれませんが、クラスパス上の他のJARファイル（も）を使用してプログラムを実行することが必要だと思います。

たとえば、A.jarにコアがあり、B.jarにライブラリがあるとします。このようにプログラムを実行できます（Windowsでは：を;に置き換えます）：

java -cp A.jar:B.jar main.class.Name args

main.class.Nameメインクラス名はどこにあり、すべてのコマンドライン引数はどこにありますかargs。

次のようにMain-Class、Class-Path属性を入力することもできます。manifest.mf

Class-Path: B.jar
Main-Class: main.class.Name

次に、次のようにプログラムを実行できます。

java -jar A.jar args

実を言うと、私は、アプリケーションを単一のJARファイルとして配布し、すべての依存関係を抽出して単一の巨大なJARファイルにラップするのは賢明だと思っていました。問題は、一部のアプリケーションでかなりの数の依存関係が発生することです。コードに変更を加えるたびに、依存関係に何も変更されていなくても、すべての依存コードを配布する必要がありました。これは、小さな変更があったとしても、巨大なJARファイルを配布することを意味しました。

マニフェスト属性を使用するClass-Pathことで、単一のJARファイルとまったく同じ方法で実行できるアプリケーションを配布できます（一部のシステムではダブルクリック、または単純な " java -jar"呪文）が、転送しないことで時間と帯域幅を大幅に節約できます後続のソフトウェアリリースで重複するすべてのライブラリ。

依存するJARを独自のディレクトリに配置し（今はそれを呼び出しましょう）、すべてのJARパスが「」のようになるようにlib変更することもできます。そうすれば、メインプログラムディレクトリが多くの小さなJARファイルでいっぱいになることはありません。Class-Pathlib/B.jar

于 2009-08-11T06:22:23.360 に答える