この質問に対する最も支持された回答は、匿名の内部クラスを反映するための回避策として、特定のフォルダーで特定の名前のクラス ファイルを検索することを提案しています。Javaクラスファイルの名前と場所が指定されているドキュメント(存在する場合)は?
VM-specには、クラス ファイルの形式の詳細な仕様が含まれていますが、それらの名前の付け方や格納場所に関する仕様はないようです。同様に、言語仕様はこの主題に触れていないようです。
クラス クラスのソース コードから(getSimpleName メソッド) :
1137 // According to JLS3 "Binary Compatibility" (13.1) the binary
1138 // name of non-package classes (not top level) is the binary
1139 // name of the immediately enclosing class followed by a '$' followed by:
1140 // (for nested and inner classes): the simple name.
1141 // (for local classes): 1 or more digits followed by the simple name.
1142 // (for anonymous classes): 1 or more digits.
言及されたドキュメント:JLS3「バイナリ互換性」(13.1)は、次のように述べています(より正確ですが、簡潔ではありません):
さらに、結果のクラス ファイルには特定のプロパティが必要です。これらのプロパティの多くは、バイナリ互換性を維持するソース コード変換をサポートするために特別に選択されています。必要なプロパティは次のとおりです。
クラスまたはインターフェイスは、次の制約を満たす必要があるバイナリ名で命名する必要があります。
トップレベルの型 (§7.6) のバイナリ名は、その正規名 (§6.7) です。
メンバー型のバイナリ名 (§8.5、§9.5) は、すぐ外側の型のバイナリ名、$、メンバーの単純名で構成されます。
ローカル クラスのバイナリ名 (§14.3) は、すぐ外側の型のバイナリ名、$、空でない一連の数字、ローカル クラスの単純名で構成されます。
匿名クラス (§15.9.5) のバイナリ名は、すぐ外側の型のバイナリ名、$、空でない一連の数字で構成されます。
ジェネリック クラスまたはインターフェイス (§8.1.2、§9.1.2) によって宣言された型変数のバイナリ名は、すぐ外側の型のバイナリ名であり、その後に $ が続き、その後に型変数の単純な名前が続きます。
ジェネリック メソッド (§8.4.4) によって宣言された型変数のバイナリ名は、メソッドを宣言する型のバイナリ名であり、その後に $ が続き、その後に Java™ 仮想マシン仕様で定義されているメソッドの記述子が続きます。 Java SE 7 Edition の後に $ が続き、その後に型変数の単純な名前が続きます。
ジェネリック コンストラクター (§8.8.4) によって宣言された型変数のバイナリ名は、コンストラクターを宣言する型のバイナリー名であり、その後に $ が続き、その後に Java™ 仮想マシン仕様で定義されているコンストラクターの記述子が続きます。 Java SE 7 Edition の後に $ が続き、その後に型変数の単純な名前が続きます。
したがって、一般的に知られている命名スキームは完全に正規化されており、それを信頼することができます (必要なクラス ファイルを見つけるためにすべてのクラス ローダーに依存する必要があるため)。
命名スキームは(おそらく)実装の詳細であるため、正式な意味で指定されていないと思います。