「古い Java との互換性」とは何を指しているか
「古い Java との互換性」というとき、実は複数のレイヤーの話が混ざっています。
コンパイルしたクラスファイルが、どのバージョンの JVM で動くかという「バイナリ互換性」。
ソースコードが、どのバージョンの Java コンパイラでコンパイルできるかという「ソース互換性」。
新しい書き方（ラムダ、Stream、record など）を導入しつつ、古いコードやライブラリと一緒に動かせるかという「設計上の互換性」。
実務では、この三つを意識しながら「どこまで新しい機能を使うか」「どこまで古い環境をサポートするか」を決めていきます。
バイナリ互換性：どの JVM で動かすか
target を下げれば「古い JVM でも動く」クラスを作れる
Java のコンパイラには、--release や -source / -target というオプションがあります。
例えば、開発環境は Java 17 だけれど、実行環境は Java 8 という場合、コンパイル時に「Java 8 向けのクラスファイル」を出力するように指定できます。
イメージとしては、次のような感じです。
javac --release 8 MyApp.java
こうすると、「Java 8 で理解できるバイトコード」が生成されます。
ただし当然ながら、「Java 8 に存在しない API や言語機能」は使えません。
つまり、「新しい JDK でコンパイルしつつ、古い JVM で動かす」ことはできるが、「古い JVM が知らない機能」は封印する必要がある、ということです。
実行時の JRE が最終的な制約になる
どれだけモダンな書き方をしても、最終的に動かす JVM が Java 8 なら、
Java 9 以降で追加された API やモジュールシステムには依存できません。
「開発マシンの JDK バージョン」と「本番サーバーの JVM バージョン」は、必ず分けて考える癖をつけてください。
互換性の話は、最終的には「どの JVM で動かすか」に収束します。
ソース互換性：古いコードを新しい JDK でコンパイルする
ほとんどの場合「そのままコンパイルできる」
Java は後方互換性をかなり重視しているので、
Java 6 や 7 時代のコードを、Java 17 などの新しい JDK でコンパイルしても、たいていはそのまま通ります。
例えば、昔ながらの for 文、匿名クラス、Date / Calendar ベースのコードなどは、
新しい JDK でも普通にコンパイル・実行できます。
つまり、「古い書き方のコードが新しい JDK で動かなくなる」という心配は、基本的にはあまりしなくて大丈夫です。
たまに「非推奨」や「削除」にぶつかる
ただし、長い歴史の中で「非推奨になった API」や「本当に削除された API」もあります。
コンパイル時に warning が出たり、まれにエラーになることもあります。
この場合は、モダンな代替 API（java.time や新しい HTTP クライアントなど）に置き換えることを検討します。
「古いコードをそのまま動かす」のか、「この機会に少しずつモダン化する」のかは、プロジェクトの方針次第です。
設計上の互換性：古いコードと新しい書き方をどう共存させるか
古いコードを「無理に全部書き換えない」
大きな既存システムでは、Java 5〜8 時代の書き方が大量に残っています。
これを一気にラムダや Stream に書き換えるのは、リスクもコストも大きいです。
現実的な戦略は、「新しく書くコードからモダンにする」「触るついでに少しずつモダン化する」です。
例えば、新しく追加するメソッドでは Optional を使うが、既存のメソッドシグネチャはそのままにしておく、などです。
「古い部分は古いままでも動く」「新しい部分はモダンなスタイルで書く」
この共存状態をしばらく続けるのが、実務ではよくある形です。
Optional や Stream を「境界」でどう扱うか
古いコードは null 前提、新しいコードは Optional 前提、という状況はよく起こります。
このときは、「境界」で変換するのが現実的です。
例えば、古いメソッドがこうだとします。
User findUser(String id); // 見つからなければ null
新しいコード側では、ラッパーを用意して Optional に変換します。
Optional<User> findUserOptional(String id) {
return Optional.ofNullable(findUser(id));
}
呼び出し側は、findUserOptional を使うことで、モダンな Optional ベースの書き方ができます。
内部の実装は徐々に置き換えていけばよく、「一気に全部直さないといけない」というプレッシャーを減らせます。
Stream も同様で、古いコードが List を返しているなら、
新しいコード側で list.stream() として扱えばよく、
「戻り値の型をいきなり Stream に変える」必要はありません。
インターフェースの default メソッドで「古い実装を壊さない」
メソッド追加で既存実装がコンパイルエラーになる問題
Java 8 より前は、インターフェースにメソッドを追加すると、
そのインターフェースを実装しているすべてのクラスでコンパイルエラーになりました。
例えば、こういうインターフェースがあったとします。
public interface Repository {
User find(String id);
}
ここに新しいメソッドを追加したくなったとき、Java 7 まではこうなります。
public interface Repository {
User find(String id);
List<User> findAll(); // 追加
}
すると、Repository を実装しているすべてのクラスで findAll の実装が必須になり、
古いコードが一斉にコンパイルエラーになります。
default メソッドで「デフォルト実装」を提供する
Java 8 以降は、default メソッドを使って「互換性を壊さない追加」ができます。
public interface Repository {
User find(String id);
default List<User> findAll() {
throw new UnsupportedOperationException("not implemented");
}
}
こうしておけば、既存の実装クラスは findAll を実装しなくてもコンパイルが通ります。
必要なクラスだけが findAll をオーバーライドすればよい。
ライブラリ設計や大規模プロジェクトでは、
「インターフェースにメソッドを追加したいが、既存実装を一気に直せない」
という場面がよくあるので、default メソッドは「互換性を守るための道具」として非常に重要です。
実務で初心者が意識しておくと良いポイント
どのバージョンを「最低サポート」とするかを決める
プロジェクトごとに、「このシステムは Java 8 以上」「このライブラリは Java 11 以上」といった「最低サポートバージョン」を決めます。
そのラインより新しい機能は使えるが、それより新しすぎる機能は使えない、という制約になります。
初心者としては、まず「自分が触っているプロジェクトの最低バージョン」を把握することが大事です。
それが分かれば、「この機能は使っていい」「これはまだ使えない」という判断がしやすくなります。
「古い書き方を見てもビビらない」「新しい書き方を無理にねじ込まない」
古いコードには、匿名クラスだらけのコールバック、Date / Calendar、null ベースの API などが普通に出てきます。
それを見て「全部ラムダと Optional にしなきゃ」と焦る必要はありません。
逆に、新しいコードを書くときに、
「このプロジェクトはまだ Java 8 だから record は使えないな」
「Optional は使えるけど、public API のシグネチャを変えるのは慎重にしよう」
といった現実的な判断ができると、一気に「実務寄りのエンジニア」になります。
まとめ：古い Java との互換性を自分の言葉で説明するなら
あなたの言葉で整理すると、こうなります。
「古い Java との互換性には、
どの JVM で動かせるかというバイナリ互換性、
古いコードを新しい JDK でコンパイルできるかというソース互換性、
古いスタイルのコードとモダンな書き方をどう共存させるかという設計上の互換性がある。
実務では、最低サポートバージョンを決めたうえで、
新しい機能はその範囲で使い、古いコードは無理に全部書き換えず、
境界で Optional や Stream に変換したり、default メソッドで API を拡張したりしながら、
少しずつモダン化していく。
つまり、『古いものを全部捨てる』のではなく、
『古いものを活かしつつ、新しい書き方を少しずつ混ぜていく』のが、
モダン Java と互換性の現実的な付き合い方。」