「Javaって、昔からあまり変わっていないのでは？」……もし仮にあなたがそう思っているならば、今のJavaを見たら驚くかもしれません。かつての冗長なイメージを脱ぎ捨て、Javaは驚くほどモダンで書きやすい言語へと進化しています。
では、その進化はいったい何を目標としているのでしょうか。そして、AIコーディング全盛の時代にJavaを選択する意義とは。Javaのスペシャリストであるきしだなおきさんに、最近のJavaが遂げている成長の全貌と、言語の未来についてお話を伺いました。
「どの言語か」よりも「どの実行環境か」が重要な時代
――今回のインタビューでは、近年のJavaの機能改善について解説していただきたいです。本題に移る前に、まず直近の大きな変化として生成AIの影響について伺わせてください。多くの方がAIエージェントを用いてコーディングするようになったことで、Javaや他の言語にどのような影響があったと思われますか？
極端な話、「プロンプトさえ自然言語で書ければ、どんな言語であってもコーディングはできてしまう」という時代になっていますよね。
例えば、僕はAIにPythonやJavaScriptを書いてもらうことがありますが、正直、生成されたコードの中身はほとんど見ません。Javaだったら読みますけれど。自分が個人的に使うツール程度であれば、中身を詳しく理解していなくても「動けばOK」でなんとかなってしまいます。この前提があるので、「どの言語を使うか」の重要度は下がってきている気がします。
言語そのものよりも「どこで動かすか」、つまり実行環境のほうが重要になっている。ここで言う実行環境とは、ネイティブやブラウザ、Android、iOSなど。それらと並ぶ選択肢としてJVMがあります。つまり、Javaという言語が良いか悪いか以前に、「JVMという環境を選ぶ理由」が問われている時代なんです。
――その理由とは、具体的に何でしょうか？
JVMの強みは、やはり動作が安定していて、セキュリティ的にも堅牢なことですね。企業の基幹システムのように高い安定性が求められる領域では、「JVMという層に守ってもらうこと」の価値が依然として高いです。
Javaは基本的に、JVMという閉じた環境だけですべてを完結させる必要があります。特定のOSのDLLやネイティブコードに依存してしまうと、環境を選ばずに動くというJavaの強みが損なわれてしまいますから。それは裏を返せば「JVMの機能だけで実現できないことは、Javaの弱点になる」ということでもあります。
この前提を踏まえて最近のJavaの改善に目を向けると、Project AmberやProject Loom、Project Panamaといった各種プロジェクトは、一言で言えば「Javaを採用しない理由を潰していくこと」が主目的だと思っています。
【補足】現在のJavaは、特定の課題解決を目指す複数の「独立したプロジェクト」が、それぞれ並行して開発を進める形で進化しています。それぞれの成果は、半年ごとの定期アップデートを通じて、準備が整ったものから順次Java本体へと取り込まれています。
- Project Amber
- 目的：開発者の生産性向上、入門者の学習しやすさの向上
- Javaの文法をより簡潔でモダンにし、正しさを保証できる範囲を広げたり冗長な記述を削減したりすることを目指しています。
- Project Loom
- 目的：スケーラビリティの向上と非同期処理の簡略化
- 従来のOSスレッドに依存しない軽量なスレッドを導入し、大量の並行処理をシンプルに記述できるようにします。
- Project Panama
- 目的：Javaと外部コード（C/C++等）の接続を安全・高速にする
- 複雑だったJNI（Java Native Interface）に代わる、安全で効率的なネイティブコード・メモリへのアクセス手段を提供します。
JVMというサンドボックスの中にいながら、「他の言語なら当たり前にできていたこと」をJavaでもできるようにする。そうやって弱点を一つひとつ着実に埋めていこうとしているのが、近年の進化の全体像だと捉えています。
機能が実態に追いついた。Project Amberがもたらした“現状追認”の進化
――ここからは、各プロジェクトの詳細について聞かせてください。開発者の手触りという点では、Project Amberによる変化が特に大きいのでは？
Project Amber、すごくいいですよね。「書きやすい言語になったな」という実感があります。もちろん、まだ機能として足りない部分はありますが、最近のアップデートでmainメソッドもシンプルに書けるようになりましたし、開発者が本当に欲しかった機能はだいたい揃ったんじゃないでしょうか。
// 旧来のmainメソッドの書き方
public class Hello {
public static void main(String[] args) {
System.out.println("Hello Java!");
}
}
// これが以下のように書けるようになりました
void main() {
IO.println("Hello Java!");
}
――Project Amberの成果により、データをうまく扱う機能がいくつも入りました。これによって、Javaのコーディングスタイルは劇的に変わるのでしょうか？
結論からいうと、スタイルそのものは大きく変わらないと思います。というより、「すでに現場で行われていたスタイルが、ようやく書きやすくなった」というのが正しい表現かもしれません。
Spring Bootなどを使った現代のWebアプリ開発を思い浮かべてみてください。「クラス」を作る場合、その実態は単なる「メソッド置き場」になっていることが多いですよね。そこでインスタンスを作るのは、オブジェクト指向的な意味合いというより、フレームワークの都合であることが多いです。
例えば、トランザクション管理やアスペクト指向プログラミングのような処理を噛ませるためには、Javaの仕組み上、インスタンスメソッドである必要があります。staticメソッドではインターセプトして処理を差し込むのが難しいので、裏側でこっそり継承してオーバーライドするためにインスタンス化している、というのが実情です。
つまり、開発者のメンタルモデルとしては、そこで状態を持つオブジェクトを作っているわけではなく、ロジックの置き場所を作っているだけなんですね。
そのロジックの中を、データが流れていきます。HTTPリクエストとして受け取ったデータをService層へ渡して変換し、Repository層に届いたらデータベースに保存する。逆にデータベースから取得したデータを、レイヤーをまたぐごとに加工して、最終的にJSONとしてクライアントに返します。
こうした「データを受け取って、変換して、流す」というコード自体は、もうずっと昔からみんなが書いてきたものです。ただ、以前のJavaではそのための記法が冗長で、少し書きにくかった。それがAmberによって書きやすくなった、という感覚です。
――新しい概念が登場したというよりは、実態に言語仕様が追いついてきたと。
そうです、完全に現状追認ですね。これはデータ指向プログラミングというスタイルです。「みんながすでに無意識にやっていたことに、名前を付けて体系化した」という側面が強いと思います。
ただ、名前がついて言語機能として正式にサポートされることには大きな意味があります。RecordsやSealed Classesを使ってデータを分類・定義する。そして、データの中身を取り出す際にはパターンマッチングを使う。こうすることで、if文やキャストを多用していた従来のコードよりも、コードの品質や書き心地を純粋に底上げできるんです。
// Recordsのコード例
record Foo(int x, int y) {}
// これは次のようなクラスになります。
class Foo extends Record {
// 状態がprivate finalとして定義
private final int x;
private final int y;
// 追加のインスタンスフィールドは定義できない
// 状態をフィールドに設定するコンストラクタが定義される
public Foo(int x, int y) {
this.x = x;
this.y = y;
}
// 状態と同じ名前のメソッドが定義される
public int x() {
return x;
}
public int y() {
return y;
}
// 状態を反映するhashCodeが定義される
public int hashCode() { ... }
// 状態を比較するequals が定義される
public boolean equals() { ... }
// 状態を表示するtoStringが定義される
public String toString() { ... }
}
さらばコールバック地獄。Project LoomがもたらしたVirtual Threads
――次は、Project Loomについて。Java 21で正式導入されたVirtual Threadsは、長年の課題だった並行処理のスケーラビリティに対する回答だと認識しています。こちらについてもご説明ください。
大量のアクセスをさばかなければならないシステムにおいて、従来のOSスレッドだけではパフォーマンスが出ないという課題はずっとありました。そこで、これまではRxJavaなどを使ってリアクティブに書くことで解決しようとしてきたわけですが、これがいわゆる「コールバック地獄」を招き、誰もメンテナンスできないようなコードが生まれたりしていたんです。
――非同期処理の複雑さに苦しめられていた現場は多かったでしょうね。
そうです。ただ、スケーラビリティに切実に困っていた層、つまり「Virtual Threadsがあれば救われるはずだった人たち」の多くは、実はすでにJavaを離れてKotlinのCoroutinesに移行しています。
一方で、それほどスケーラビリティを求めていない大多数のJava開発者にとっては、Virtual Threadsを意識してコードを書く機会自体、あまりないんじゃないかなと思います。
――では、Virtual Threadsは多くの開発者にとって関係のない機能になってしまうのでしょうか？
いいえ、そうではありません。自分たちで意識して使うというよりは、フレームワークやミドルウェア側が勝手にVirtual Threadsの対応をしてくれて、その恩恵を「いつの間にか受ける」という形になるはずです。
設定ファイルのフラグをちょっと書き換えるだけで、あるいはバージョンを上げるだけで、スループットが向上して、今までより少ないサーバー台数で同じリクエスト数をさばけるようになる。そういった実利として効いてくるはずです。
――これによって、「JavaではなくKotlinを選ぼう」としていた層が、「Javaで十分だよね」と踏みとどまる可能性はあるでしょうか？
それはあると思います。すでにKotlinに行ってしまった人たちが戻ってくるかというと、それはたぶんないです。Kotlinは後発言語だけあって言語仕様が非常に洗練されていますし、変な落とし穴も少ない。一度その快適さを知った人が、わざわざ戻る理由は薄いですね。
ただ、「次はKotlinに移行したほうがいいのかな」と迷っていた層が、「Virtual Threadsも入ったし、最近のJavaは書きやすくなっているから、このままJavaでいい」と判断するケースは増える可能性があります。
非標準を標準へ。Project Panamaが変える、Javaとネイティブの距離感
――Project Panamaについても伺わせてください。これまでネイティブ連携といえばJNI（Java Native Interface）のつらさが代名詞でしたが、このプロジェクトによってAI・MLとの連携や、低レイヤー処理の効率化が進むのでしょうか？
Project Panamaに関していうと、「新しいことができるようになった」というより、「今まで非標準なやり方で無理やりやっていたことを、ちゃんと標準化した」という側面が強いです。
これまでも、メモリに直接アクセスしようと思えば、Unsafeを使えばできましたし、ネイティブコードを呼び出すならJNIがありました。ただ、Unsafeはその名の通り安全ではないですし、JNIは記述がとにかく大変です。JNA（Java Native Access）のような外部ライブラリを使えば比較的きれいに書けましたが、あくまでサードパーティー製でした。
それらを言語標準の機能として、安全かつスマートにやろうというのがProject Panamaの狙いです。
――では、AIやMLといった計算処理の面ではいかがでしょうか？
計算処理という点では、Project Panamaの一部であるVector APIが重要かもしれません。これはCPUのSIMD（Single Instruction, Multiple Data）命令をJavaから扱えるようにするものです。簡単に言うと、例えば「桁上がりのない小さな足し算」を、長いレジスタを使って同時に4つとか8つまとめて計算してしまう技術ですね。
――それは高速化にかなり寄与しそうですね。
ただ、今のAIブーム、特にLLM（大規模言語モデル）の文脈で考えると、CPUのSIMD命令だけでは厳しいのが現状です。今求められているのは、CPUによるSIMDではなく、GPUを使ったSIMT（Single Instruction, Multiple Threads）、つまり「桁違いに大量の並列計算」なんですよね。残念ながら、Javaは標準機能としてGPUを効率的に使う手段を持っていません。ここがAI分野におけるJavaの大きなネックになっています。
AIやLLMが発展している環境には、必ず強力な「行列計算ライブラリ」が存在します。PythonならNumPyがあり、その上にPyTorchなどが乗っていますよね。最近話題のローカルLLM実行環境であるllama.cppも、ベースにはGGMLという強力な機械学習ライブラリがあります。
Javaには、この「標準的な行列計算ライブラリ」に相当するものがありません。だから、「Java上でLLMを動かそう」と思っても、土台となる足回りがないんです。個人的には、GPUのパワーを裏側でしっかり活かせる「標準的な行列計算ライブラリ」がJava本体に入ってきてほしいな、と思っています。
インタビューを受けるきしださん
Project Valhallaが変える常識。Javaのボトルネックが解消される未来
――今後の展望についてもお聞かせください。例えば、Project Valhallaなどの大きなトピックも控えていますよね。
- Project Valhalla
- 目的：Javaのデータモデルとメモリ管理の根本的な改善
- Value Objectsの導入により、Javaにおける型システムを現代的に再定義することを目指しています。
Project ValhallaのValue Typesは、かなり重要な機能です。これはプリミティブ型の性能を持ちながらクラスのように扱えるもので、プログラマが特定のクラスに「nullを許容するかどうか」を制御できるようになります。
これによって、Javaエンジニアがずっとやりたかった「null安全性」がようやく完成形に近づくわけです。これに合わせて、Null-Restricted Types（null制限型）のような構想もドラフト段階まで進んでいます。
Value Typesがかなり有望なので、他の機能の開発の大部分が「Project Valhalla待ちで止まっている」というのが現状なんですよね。例を挙げると、さきほどお話ししたVector APIもそうです。
Value Typesが入らなければ性能をフルに出せないですし、正式版になったあとに仕様を変えるわけにもいきません。だから、Value Typesが入るまでは正式化できないんです。逆にいえば、Value Typesさえ入ってくれば、複数の機能が一気に改善していくはずです。
――相当に有望な機能なのですね。
null安全性についても補足すると、「nullが入らない型」を作った場合、「じゃあ、変数の初期値は何になるの？」という問題が出てきます。これまでのオブジェクトならデフォルトはnullでよかったんですが、Value Typesはnullを拒否できます。となると、その型ごとに「デフォルト値はこれ」と定義する仕組みが必要になります。
ですが、今のJavaのインターフェースは「インスタンスメソッド」の定義、つまり「生成されたあとのオブジェクトに対して何ができるか」しか強制できません。「インスタンスができる前の、型としての決まりごと」を強制する仕組みが、今のJavaにはないんです。
そこで注目されているのがType Classes（型クラス）であり、JVM Language Summit 2025で言及されています。Type Classesがあれば、「この型のデフォルト値はこれ」といった、型そのものに対する制約を記述できるようになります。
"Growing the Java Language #JVMLS" | YouTube
Type Classesについて語られているセッション
――Type Classesが入ることで、Javaの表現力が一気に広がりそうですね。
ただ、実際の開発現場で開発者たちがガリガリと型クラスを定義するようになるかというと、たぶんそうはならないと思います。おそらく、フレームワークやライブラリの開発者たちが型クラスを駆使して便利な機能を作り、僕たちはそれを利用する流れになるはずです。
裏側の仕組みを知らなくても「なんか、フレームワークがすごく便利になった」という恩恵を受ける。そんな未来がやってくるはずです。実現まで、時間はまだかなりかかると思いますけれど。
JavaはAIとの親和性も高い言語。ぜひ、最新バージョンに触れてみよう
――多くの現場では依然としてJavaの古いバージョンが稼働しており、新しいバージョンへの移行に足踏みしているケースも少なくありません。きしださんが、そうした現場の方に「今、バージョンを上げるべき理由」を説得するとしたら、どのポイントを強調されますか？
正直にいうと、「別に無理に上げなくてもいいんじゃない？」と言いたい気持ちもあるんですよ（笑）。お金さえ払えば古いバージョンでもサポートは続きますし、ビジネスとしてそれで回っているなら、バージョンを上げないことも一つの選択肢ですから。
ただ、「今後も長くシステムを維持・発展させていきたい」と考えているなら、やはりどこかのタイミングで頑張って上げるべきだと思います。
Java 8から11、そして11から17への移行が一番大きなハードルですね。非互換な変更がいくつかありますから。でも、そこさえ乗り越えてしまえば、あとは楽になるはずです。Java 17以降は、既存のコードが動かなくなるような破壊的な変更はもうあまり入らないと予想されています。
――バージョンを上げた先に、どのような利益を享受できるのでしょうか？
まずわかりやすいのは、実行環境の改善ですね。コードを1行も書き換えなくても、新しいJVMで動かすだけで起動が速くなり、ガベージコレクションも賢くなってパフォーマンスが向上します。
開発者にとってのメリットは、コーディングの質が変わることです。今のJavaはほかの言語のいいところを取り入れて、かなりモダンなコードが書ける言語になりました。昔ながらの冗長な記述ではなく、簡潔で安全なコードが書けるようになっています。
――最後に、改めて「Javaの未来」への期待をお聞かせください。
今、生成AIの普及によって、Javaという言語単体の未来だけでなく、「プログラミングそのものの未来」を考えなければならないフェーズに来ています。
その中で幸いなことに、Javaは「AIとの親和性が高い言語」の1つになっています。静的型付けによる適度な制約と、強力なガベージコレクションがあるおかげで、AIが品質の高いコードを生成しやすいんです。
ただ、人間が書くにせよAIに書かせるにせよ、ベースとなるJavaのバージョンが古いままだと、その恩恵を十分には受けられません。ぜひ、最新のバージョンに触れてみてほしいですね。