最近、開発、テスト、およびビルド ディレクトリの削除を行っていましたが、これにより発生するエラーが想定よりも少ないことに気付きました。
Javaアプリケーションの実行中にクラスファイルのディレクトリを削除するとどうなるかについて、誰かが詳細な説明を提供できるかどうか興味があります. ある時点で、これはアプリケーションに影響を与えないと思います (つまり、すべての操作がバイト コードとしてスタックにプッシュされるため)。JVM は、ある時点で、実行中のアプリケーション内のすべてのクラスのキャッシュまたは完全な所有権を取得して、最初の場所 (つまり、最初に Java プロセスの実行を開始したときの .class ファイルの場所) はもはや重要ではありませんか?
クラスファイルは、最初にアクセスするときに必要です。通常はキャッシュされませんが、代わりにClassLoaderが必要なすべての情報を抽出し、.class再度読み取ることはありません。
通常、ベストプラクティスは、新しいバージョンを作成するときに、最後のバージョンがまだライブである場合（または、そのバージョンにロールバックする機能が必要な場合）に新しいディレクトリに書き込むことです。
実行中にプログラムを削除/編集すると、シェルスクリプトとCプログラムで問題が発生するため、Javaではうまく機能しないことは驚くべきことではありません。
@Louis Wassermanが指摘しているように、OPは、予想よりもうまく機能すると述べています。アプリケーションに依存するIMHO。必要なすべてのクラスがロードされている場合は、それらをすべて削除できます。起動してからずっと後にクラスをロードするアプリケーションは、このように動作しません。
現在、ほとんどの JVM は「オンデマンド」方式でクラスをロードするため、Java プログラムを開始すると、JVM はアクティブな参照に基づいて必要に応じて .class ファイルを読み込みます。(それよりも複雑ですが、簡単にするために、現実に近いと仮定します。) ロードされると、ディスク上のバイトは JVM 内部表現に変換されてメモリに保持されるため、不要になります。事実上、いったんクラスがロードされると、それらをディスク上に置く必要はなくなります (まったく同じプログラムをゼロから実行することは二度とないと仮定します!)。
ただし、大きな問題があります...プログラムのすべてのクラスが実際に平均的な実行で読み込まれるわけではありません。特殊な状況でのみ必要となるエラー クラスを想像してみてください。通常の実行ではロードされないため、プログラムが「通常」に実行されているときにファイル システムからすべてを単純に削除し、後でクラスのロードが必要なエラー状態に陥った場合、JVM は二重のエラーで失敗します。悪い方法 - 予想される例外 (通常は catch ブロックを介して処理される) をスローするのではなく、より深刻なエラーが発生し、ロジックが脱線します。
すべてのクラスを「プリロード」することは可能ですが、これはちょっとしたハックであり、通常は、アプリ内のすべてのクラスのリストを保持し、それぞれに対して「Class.forName()」を実行するなどの手間で実現されます。パフォーマンス上の理由で人々がどのようにそれを行うかについては、この SO記事を参照してください。