jar内のJavaクラスファイルは、簡単に置き換えたり変更したりできます。たとえば、次のコマンドを使用して、jar内のコンパイル済みクラスファイルを置き換えることができます。
jar uf JarFile.jar com\something\Class.class
依存関係が壊れないようにクラスファイルがファイルに置き換えられた場合でも、コードは実行できます。jar内にないクラスファイルでも同じことが起こります。
クラスファイルのセット（jar内かどうかに関係なく）を検証して、それらのすべての依存関係が存在し、壊れていないかどうかを確認する方法はありますか？
クラスファイルが変更されるのを防ぎたくはありませんが、変更が（依存関係に関して）有効であることを確認できるようにしたいのです。コンパイラはコンパイル時にこのチェック（依存関係チェック）を行いますが、クラスがコンパイルされたら、クラスファイル自体をどのように検証できますか？
アップデート：
どうやら私は私の最初の推測でマークを逃しました。
そうでない場合、あなたは何をするつもりですか？彼らがサードパーティの場合、ダウンロードが悪いことをバグデータベースに報告する以外に選択肢はほとんどないと思います。
「サードパーティのJAR依存関係がすべて正しいことを確認したい」という意味の場合、はるかに大きな問題が発生します。私が知っているほとんどのダウンロード（Springなど）は、Mavenを使用して依存関係を利用できるようにします。それがあなたにできる最善のことです。
自分の依存関係を確認したい場合は、テストによってエラーが発生したことが明らかになると思います。
いいえ、あなたがすることはできません。
少なくとも：そうではありません。問題は、Javaが実行時に必要な場合にのみクラスをロードすることです。したがって、最終的にはjarファイルからクラスを削除しても問題がない可能性があり、そのクラスを参照するコードが実行されない限り、処理は非常にスムーズに実行されます。
この例を考えてみましょう。
class A{ public static void main( String args[] ){ out.println( "hello" ); } }
class B{}
これをコンパイルし、jarに入れ、B.classを削除します。問題ありません:)
これで、各.classファイルを調べて、それが参照しているクラスを確認し、ファイルがすべてそこにあるかどうかを確認できると思うかもしれません。これは苦痛であるだけでなく、不完全でもあります。クラス名は実行時に作成される可能性があるため、リフレクションがロードされたファイルを完全にキャッチすることはできません。
私のアドバイス：そこに行かないでください。誰かがクラスファイルを削除した場合、それは彼ら自身の責任です。あなたができる最善のことは（しかしこれが本当にあなたを心配している場合にのみ）ClassNotFoundException実行時にsをキャッチしようとすることです（thread.setUncaughtExceptionHandlerを調べてください）
クラスをロードするだけで確実になります。