モジュール化とスケーラビリティを可能な限り維持するために、中規模のJavaプロジェクトを構築しようとしています。そのために、メイン アーキテクチャは、おそらく実行時に jar で提供される一部のクラス (モジュール) のロードのみを担当します。このソリューションには明らかに動的なクラスのロードが必要ですが、コンポーネントの結合が最小限に抑えられます。

さて、問題が発生します。各モジュールは、いくつかのライブラリに依存している場合があります (たとえば、Hibernate、Spring などとしましょう)。依存関係の地獄を避けるために、すべてのライブラリをアーキテクチャ インターフェイスと共に 1 つのプロジェクトに配置し、このプロジェクトをすべてのモジュールの依存関係として含めます。理想的には、この依存関係プロジェクトをクラスローディングから動的に除外して、実行時の問題を回避したいと考えています。

ここに私の質問があります：

• まず、これでよろしいでしょうか？私が見逃しているこの問題に対するより良いアプローチはありますか?
• これは私が気にするべきことですか？または、同じクラスを複数回含めているという事実は問題になりませんか?
• それが問題である場合、そのクラスをロードから除外する最善の方法は何でしょうか? パッケージごとにフィルタリングすることを考えていましたが、よくわかりません。

この種のアーキテクチャを使用するのか、代わりに Maven を使用して各モジュールの依存プロジェクトを除く完全なプロジェクトを静的にビルドするのか、まだよくわかりません。

続行する方法についての提案は本当に感謝しています。

現時点では、Maven を使用してビルドし、Spring をフレームワークとして使用していますが、他のテクノロジーを追加してもかまいません。

ありがとうございました。

いくつかのサードパーティの jar によってクラスパスを拡張するクラスローダーを作成したいと思います。現在、私のコードは次のようになっています。

問題は、使用したクラスのロードが正常に機能する場合でも、ロードされたクラスのClassLoader#loadClassメソッド#getClassLoaderがカスタムのクラスローダーではなく元のクラスローダーを返すことです。このような状態では、追加の jar を認識せず、依存関係をロードできないため、呼び出しclassFromJar.newInstance()がスローされます。ClassNotFoundExeptionoriginalClassLoaderclassFromJar

ロードされたクラスの結果に自分自身を伝播するカスタムクラスローダーを作成する方法はClass#getClassLoader?

-Djava.system.class.loader「java.class.path」システム プロパティまたは JVMスイッチをカスタマイズせずに、純粋に実行時にそれを実現したいと思います。

Java で、それ自体をロードする (またはより適切にリロードする) クラスローダーを作成することは可能ですか?

最初は、デフォルトのクラスローダーによってロードできます。コンパイルとロードのサイクルを介して実行されているときに、それ自体を変更できる Java のシステムを想像します。もしそうなら、ロシア人形ローダーから継承する多くのオブジェクトを作成して、それらのロジックを動的に更新することができます。

動的クラスローディングメカニズムがどのように機能するかについて、少し混乱しています。以下のクラスを実装し、それらがすべて同じ src ディレクトリにあり、IDE、サーバー、およびクライアントの作業からそれらを起動します。しかし、私がそれらを分離すると、私はそれを機能させることができません。RMIの仕組みなどを説明するガイドはたくさんありますが、ファイルを分割して起動する方法については説明していません。

だから私がやったこと：すべてのクラスをコンパイルし、対応する.classファイルを取得しました。次に、フォルダーとサブフォルダーを作成して、クライアント、サーバー、および共通クラスを分離しました。

これは宿題の質問サーバーであり、クライアントは両方とも localhost で動作します。とにかく、次にサーバーを起動するとき

クラスが見つからない

では、それを機能させるにはどうすればよいですか？私のクラス分けは正しいですか？サーバーとクライアントを起動するにはどうすればよいですか? ありがとう。

以下に私のクラスがあります：

私は2つのクラスを持っています

これは C:\NNK\pack2 にあります。完全修飾名は pack2.eg です

別のプログラムは

このプログラムは C:\NNK にあります。eg プログラムをここにロードする必要があります。私はOracleでそれを学ぼうとしましたが、それに関する他の関連するスタックオーバーフローの質問を見ました。 Javaでクラスを動的にロード する また、ディレクトリのファイル名 (例: C:\NNK\pack2\eg) を使用してクラスをロードする方法はありますか?

私はクラスの読み込みが初めてなので、何か間違っている場合は助けてください。

スレッド「メイン」の例外 java.lang.ClassNotFoundException: java.net.URLClassLoader.findClass(URLClassLoader.java:381) でこんにちは java.lang.ClassLoader.loadClass(ClassLoader.java:424)

Java が最初のアクセス (新しいインスタンスの作成、静的メソッドまたは静的フィールドの呼び出し) でクラスをロードすることは知っていますが、この単純な例では、実行時に ClassPath にないいくつかのクラスを使用する jar ファイルを実行しようとしています。例外が発生する前に、（最初のアクセスでクラスをロードするため）静的ブロックとメインメソッドにメッセージを出力することを期待しています。しかし、「スレッド「メイン」の例外 java.lang.NoClassDefFoundError: com/example/DateAbstract」が表示され、何も出力されませんでした。これは、クラスまたはインターフェースが別のjarファイルにあるメインクラスで抽象クラスまたはインターフェースを使用したときに発生しました。

私の別の瓶で：

このコードを使用して、実行時にクラスをクラスパスに追加すると。何も変わっていません。静的ブロックを実行する前に実行を取得しました。

質問 : なぜこれが起こっているのか、どのように解決すればよいのですか?

簡単な要約は次のとおりです。APK と個別のライブラリ (JAR、AAR、DEX ファイルなどの何らかの形式でクラス (および理想的にはリソースも) のセットを意味します) をビルドする方法ですが、それらのライブラリをAPK; 代わりに、アプリは実行時にそれらをロードしますか?

詳細

したがって、私の主な質問は、そのようなアプリを構築する方法です (Gradle 構成など)。どのクラスがどの JAR ファイルまたは DEX ファイルに入るかを指定するにはどうすればよいですか? 最終的に作成したい DEX ファイルごとに Android Studio モジュールを作成する必要がありますか?

密接に関連する質問は、Java コードが外部ライブラリをロードし、実行時にそれらのクラスにアクセスする方法です。後者については、classloader による dex ファイルからアプリのクラスへのアクセスで示されたアプローチが機能することを願っています。

https://developer.android.com/studio/projects/android-library.htmlの手順を試しましたが、依存関係ライブラリを含むAPK がビルドされます。

Multidex ( https://developer.android.com/studio/build/multidex.html )も試してみましたが、開発者がどのクラスをどのDEXファイルに入れるかを制御できないようです。さらに、それらすべてを 1 つの APK にパッケージ化します。AFAICT 実行時にこれらの DEX ファイルのロードを制御する方法はありません。

バックグラウンド

ここで「 XY問題」の可能性があるので、背景を説明したほうがいいです。

クライアント向けのアプリを構築しています。アプリ ストアを通じて配布される予定はないため、更新のための通常のメカニズムにはアクセスできません。代わりに、クライアントは、新しい APK を手動でサイドロードする必要なく、アプリ自体の新しいコンポーネントをダウンロードして古いコンポーネントを置き換えることでアプリ自体を更新できるようにしたいと考えています。ここでの主な動機は、更新が技術者以外のユーザーにとって簡単でなければならないということです。アプリが更新プロセスを制御できる場合は、更新プロセスをスムーズにし、ユーザーをガイドできます。

さらに、このアプリはインターネット アクセスが不十分で高価な地域で使用されるため、クライアントは、ユーザーにアプリ全体を再ダウンロードさせて更新を受け取るのではなく、小さなチャンク (2 MB など) でアプリの更新を発行できるようにしたいと考えています。小さなアップデート。

重要な場合に備えて言及する必要がある要件の 1 つの側面は、実行時に読み込まれるライブラリが microSD カードに存在することになっていることです。これは、インターネットにアクセスせずに更新を配布する場合にも役立ちます。

アプリの現在のステータスは、約 50% が作成されているということです。つまり、以前のバージョンがいくつかリリースされていますが、上記の要件やその他の要件を満たすために、アプリを変更 (再構築) する必要があります。