問題と範囲
Java 25へのアップグレード後、あるチームが小規模なユーティリティにコンパクトソースファイルを使用したいと考えています。エントリポイントの選択、暗黙的に宣言されたクラスのメンバー、自動インポートの境界、およびこの機能を本番環境で採用すべきかどうかをどのように判断するかを説明してください。
JEP 512は、プレビューリリースを経てCompact Source FilesおよびInstance Main Methodsを正式機能（final）としました。ファイルではトップレベルのクラス宣言を省略できます。トップレベルのフィールド、メソッド、およびネストされた宣言は暗黙的に宣言されたクラスのメンバーとなり、ランチャーは定義されたプロトコルに従って起動可能なmainメソッドを検索します。
面接官がテストしていること
構文糖衣の背後にある実際のクラスモデル、引数なしと配列引数のエントリポイントの違い、java.baseのオンデマンドインポートとIO境界、コンパイルおよび実行コマンド、ドキュメントとデバッグの制限、そして段階的な導入戦略について網羅してください。
30秒での回答
「私はこれを、単一ファイルスクリプト、教育用サンプル、および使い捨てツールのボイラープレート削減手段として位置づけます。コンパイラはObjectを継承するクラスを暗黙的に宣言し、トップレベルのメンバーはそのクラスのメンバーになります。ランチャーはまずアクセス可能なvoid main(String[])を選択し、それがなければアクセス可能なvoid main()を選択します。インスタンスエントリポイントはデフォルトコンストラクタの実行後に呼び出されます。Java 25はjava.baseによってエクスポートされたパブリックなトップレベル型をオンデマンドでインポートしますが、IOのstaticメソッドは暗黙的にインポートされません。パブリックライブラリや複雑なサービスには明示的なクラスを維持し、まずターゲットJDK、ビルドツール、およびドキュメントパイプラインを検証します。」
ステップバイステップの解決策
ステップ 1: 暗黙的に宣言されたクラスを特定する
クラス宣言で囲まれていないソースファイルは、暗黙的にクラスを宣言します。これはObjectを継承し、デフォルトの引数なしコンストラクタを持ち、他のソースコードが直接参照できないホストによって選択された名前を受け取ります。ファイル内のフィールド、メソッド、およびネストされた宣言は、そのクラスのメンバーになります。
ステップ 2: 起動可能なエントリポイントを決定する
ランチャーはまず、String配列パラメータを持つアクセス可能なvoid mainを検索します。存在しない場合は、パラメータのないアクセス可能なvoid mainを検索します。選択されたメソッドがインスタンスメソッドである場合、ランチャーはそれを呼び出す前に暗黙のクラスのインスタンスを生成します。
void main(String[] args) {
IO.println("hello " + args[0]);
}ステップ 3: 自動インポートを理解する
コンパクトソースファイルは、java.baseによってエクスポートされたパブリックなトップレベル型をオンデマンドでインポートしているかのように動作するため、MapやStreamなどの型は通常、明示的なインポートを必要としません。これは任意のモジュールをインポートするわけではなく、IOのstaticメソッドも暗黙的にはインポートされません。IO.printlnを呼び出すか、明示的なstaticインポートを追加してください。
ステップ 4: 実行モードとコンパイルモードを区別する
java Hello.javaを実行してランチャーにファイルのコンパイルと実行を行わせることも、javac Hello.javaを実行した後に生成されたクラスを実行することもできます。直接ソースを実行する方法は短いスクリプトには便利ですが、再現可能なビルド、キャッシング、およびリリースパイプラインでは、引き続き既知の出力ディレクトリへ明示的にコンパイルする必要があります。
ステップ 5: 状態とライフサイクルを分析する
トップレベルのフィールドは暗黙のクラスのフィールドになるため、インスタンスmainはインスタンスの状態を読み取ることができます。ランチャーはデフォルトコンストラクタを使用するため、外部からのコンストラクタ引数注入はこのプロトコルの一部ではありません。複雑な初期化、複数のエントリポイント、または明示的なライフサイクルは、名前付きクラスの方がレビューしやすくなります。
ステップ 6: ツールの境界を評価する
暗黙的に宣言されたクラスには他のクラスが参照できる安定したソースレベルの名前がなく、javadocは従来のAPIを生成できません。IDE、静的解析ツール、カバレッジツール、およびデバッガは、バージョンによってこの構文のサポート状況が異なる場合があります。ターゲットJDKとビルドプラグインを併せて検証してください。
ステップ 7: 移行とロールバックを設計する
まずスクリプトや教育用サンプルを別のディレクトリに移動し、ロールバック用として明示的なクラスバージョンを保持します。CIでJava 25を固定し、javaとjavacのバージョンが一致していることを確認し、パッケージング、ログ、例外トレース、およびコンテナコマンドが実装クラス名に依存していないことを検証します。
ステップ 8: 導入の境界を定義する
採用するかどうかは、コードが安定したAPI、依存性注入、監視可能なエントリポイント、またはモジュール間での再利用を必要とするかどうかに依存します。単一ファイルの運用ツールは定型構文が減ることでより明確になりますが、共有ライブラリ、長時間実行されるサービス、またはドキュメント化されたAPIは通常、明示的なクラスの恩恵を受けます。
トレードオフと境界
シンプルさか発見しやすさか
コンパクトファイルは初心者のサンプルをその意図に近づけますが、暗黙的な名前やインポートルールによって必要なツール知識の量が増加します。この機能は結合度の低いディレクトリに限定し、コーディング規約でその境界を文書化してください。
インスタンスmainかstatic mainか
インスタンスmainはフィールドやインスタンスメソッドを直接使用できるため、状態を持つデモンストレーションに適しています。static mainは従来のJavaの起動パスにより近くなります。いずれにせよ、ランチャーが複数の候補を報告しないように、エントリのシグネチャは一意にしておきます。
自動インポートか明示的なインポートか
java.baseのオンデマンドルールにより教育用コードからインポートが削除されますが、他のモジュールの型には依然として明示的なモジュールインポートまたは通常のインポートが必要です。共有される本番コードでは、読者が暗黙のルールを記憶していることに依存するのではなく、依存関係を明確に記述すべきです。
障害訓練と発展
複数のmain候補
引数なしとString配列のエントリポイントの両方を追加し、配列形式が優先されることを確認します。戻り値の型や可視性を変更し、ランチャーのエラーおよびフォールバックの動作を確認します。
暗黙のクラス名への依存
2つ目のソースファイルから生成されたクラス名を参照させ、コンパイルが失敗することを確認した上で、共有ロジックを明示的に名前を付けたクラスに移動します。
一致しないツールチェーン
同じファイルを古いJDKとJava 25でコンパイルします。構文エラーを実行時まで遅らせるのではなく、言語レベルの不一致によってCIが即座に失敗するようにすべきです。
よくある間違いとフォローアップ
間違い 1: ファイルにクラスが存在しないと思い込む
フォローアップ: トップレベルのメソッドやフィールドはどこに配置されますか？それらはコンパイラが生成した暗黙のクラスのメンバーであり、メンバーおよびインスタンスのライフサイクルのルールに引き続き従います。
間違い 2: すべてのインポートが自動であると思い込む
フォローアップ: なぜIO.printlnでクラス名を指定する必要があるのですか？IOのstaticメソッドは暗黙的にはインポートされません。オンデマンドでインポートされるのはjava.baseのパブリックなトップレベル型です。
間違い 3: スクリプト構文を安定したAPIとして扱う
フォローアップ: 他のモジュールが暗黙のクラスに依存することはできますか？実装名に依存することはできません。再利用可能なAPIは、明示的に名前が付けられたクラスに属します。
より深いフォローアップと模範解答
なぜインスタンスmainにはデフォルトコンストラクタが必要なのですか？
インスタンスエントリポイントが選択された後、ランチャーは暗黙的に宣言されたクラスを構築し、その後にメソッドを呼び出します。コンパクトファイルにはコンストラクタ引数のプロトコルがないため、外部からの注入には明示的なクラスが必要です。
ソースの直接実行は事前のコンパイルとどのように異なりますか？
直接実行では、javaランチャーが一時的にコンパイルしてソースを実行するため、短いスクリプトに適しています。事前にjavacでコンパイルすると、CIやリリースシステムに対して安定したアーティファクト、キャッシング、および診断情報が提供されます。
どのような場合に明示的なクラスに戻すべきですか？
単一ファイルの形式よりもボイラープレートが増えるとしても、安定した型名、パブリックAPI、javadoc、依存性注入、複数の構築パス、またはモジュール間での再利用が必要な場合は、明示的な名前付きクラスを使用してください。