6
最近、実行時にjarファイルをアプリケーションに動的にロードする方法を探していました。リフレクションを使用してランタイムにクラスパスにファイルを追加する危険性
私は、システムクラスローダーを取得し、リフレクションを使用して、実行時に元のクラスパスに追加のファイルを追加するために、別の孤立したaddURLメソッドにアクセスする基本的な "ハック"このソリューションは、実際にうまく動作し、自作カスタムクラスローダーを作成して使用する際に発生する問題を回避します。
それはこのようなものになります。次のように私の質問がある
を：私は最初の場所で保護さaddURL方法を作るための本当に良い理由があると仮定し、落とし穴のいくつかの種類が存在しなければなりませんか、クラスパスにファイルを動的に追加する際に危険です。
システムクラスローダーは常に「この場合」（TM）であるURLClassLoaderであると仮定すると、この「ハック」を使用するとどのような問題が発生する可能性がありますか？
おかげ
方法
protectedを作ることを選択し、述べて余分なjarファイルについて知っていますか？ –私は正直であることを完全に確信していません。私は一般的なクラスローダーのコンセプトにはとても新しいので、私は完全に理解していないことはまだたくさんあります。 ここで私はどこか別の場所で、カスタムクラスローダーを使用すると、たとえば、プログラムの起動時にデフォルトのクラスパス経由でロードされたライブラリをロードするために使用すると、特定の状況で問題を引き起こす可能性があります。 上記のこの「ハック」は、かなり厄介ですが、依存性/非互換性の問題にぶつかるリスクがなく、実行時にjarをロードする唯一の方法とみなされていました。 – thousands
あなたはすでにデフォルトクラスパスにあるライブラリをロードしようとしていますか？このハックは、別々のクラスローダーの*設計されたアプローチを使うよりもはるかに危険です。 –