BT

InfoQ ホームページ ニュース 2019年のJavaを予測する

2019年のJavaを予測する

ブックマーク

原文(投稿日:2018/12/31)へのリンク

2018年は,InfoQの記事でもまとめているように,Javaにとって非常に興味深い年であった。

2019年になったので,新たな年にJavaとその関連技術において注目すべきことを確認し,今年は何が起こるのかを予測してみたい。

免責事項:以下は著者の個人的な予測であり,Oracle,InfoQ,その他による公式声明あるいはロードマップといったものではない。

Java 11の小規模な,しかし重要な意味を持つ導入が始まる

これは,今回のリストの中でも最も論議を呼ぶ予測かも知れない。Java 9と10は事実上,運用環境にはまったく展開されていない。多くの開発チームが,Java 8の次のLTSリリースを待っていると思われるからだ。それが現れたのだから,Java 11は少しずつ,しかし着実に採用され始めるようになる。

採用の大きな推進力となるのは,マイクロサービスとコンテナ化アプリケーションである。いずれもJava 11では,Java 8よりもはるかに容易になっている。新たな場所に展開されるアプリケーションの新規開発は,チームにとってJava 11を採用する最高の機会になるだろう。

予測: 2019年末の報告において,Javaの実運用システム全体の約10パーセントがJava 11になる。

既存アプリケーションのJava 8から11への大規模な移植は行われない

これまでは,アプリケーションのJavaアップグレードパスは比較的明確だった。6から7,7から8へのマイグレーションは,ほとんどすべての場合,苦労を伴わない作業だったのだ。8から11へのアップグレードには,これが当てはまらない - 重要でないアプリケーションであっても,通常は,新たなバージョンへの移行に相当量の作業が必要になるのだ。

アプリケーションを移植し,アーキテクトを再構築し,すべてのテストを再実施するリソースを持つアプリケーショングループは極めて少ない。結論として,説得力のある外部的理由が他にない限り,Java 8アプリケーションのJava 11への広範な移植の実施は期待できそうもない。

予測: 数値化可能な予測は特にない。

Python 2 / Python 3のような分割は起こらない

モジュールJavaの登場により,Python 2 / Python 3でコミュニティが経験したものと同じようなラインでエコシステムが断片化する可能性については,多くの人が言及している。

これが起こらないと私が考える理由はいくつかあるが,最も大きなものは,Java 11が構文的ないし意味的なレベルにおいて,基本的に異なる言語ではないということだ。Pythonでは,構文や主要なデータ型(Unicode文字列やlongなど)の意味がバージョン間で変更されているため,ライブラリやアプリケーションの作者は,どちらの言語バージョンを対象とするかを意識的に選択しなければならない。プロジェクトを単位とするこの選択が,エコシステム全体に浸透しているのだ。

一方,Javaの場合は,モジュール構造を受け入れるかどうかはアプリケーションオーナの選択であり,ライブラリをモジュールとして提供するかどうか,そうする場合にJava 8アプリケーション用のフォールバックを提供するかどうかはライブラリ開発者の選択である。一般的なJavaプログラマは以前と同じことを続けており,従事しているプロジェクトがJava 8と11のどちらを対象としていても,基本的に同じ言語でプログラムしているのだ。

予測: 数値化可能な予測は特にない。

Graalの段階的採用

Java 11に移行したプロジェクトでは,Graalプロジェクトへの関心が高くなりそうだ。このプロジェクトには,2019年のJava 11用C2コンパイラ(別名:サーバコンパイラ)に匹敵する(あるいは凌駕する)次世代JITコンパイラが含まれている。

Graal-JITが - 遅かれ早かれ - C2を越えるのは間違いなさそうだ。Graalの設計(特にJavaで実装されているという事実)はすなわち,C2で実装可能な新たな最適化を,Graalチームは比較的容易に実装できる,ということを意味する。

包括的用語である"Graal"には,多言語用ランタイムのOracleの準オープンプロエジェクトであるGraalVMも含まれている。ただし,Graal-JITがJava 11以降でのみ使用可能であるのに対して,GraalVMはJava 8相当に過ぎない点には注意が必要だ。

これによってGraalのユーザコミュニティは,つながりを持たない2つのグループになる可能性がある。すなわち,Java 11アプリケーションのパフォーマンスを重視するグループと,Java 8エコシステムを活用した多言語アプリに重点を置くグループである。

予測:

  • Java 11アプリケーションの30~40パーセントが,Java 11の運用環境でGraal-JITを使うようになる。
  • GraalをデフォルトのJITコンパイラにする案がJava 13で真剣に議論されるが,最終的には実現しない。
  • GraalVMの運用環境への導入数は少ないものの,アプリケーションチームによる実験的利用は増加する。

OpenJDKがJavaランタイム市場のリーダになる

OracleがOpenJDK 8プロジェクトの所有権を放棄し,Red Hatがリーダとして名乗りを上げた。OpenJDK 11でも同じことが起きて,Java 12はリリース時にOracleによって放棄される可能性がある。

多くの開発者は,OracleのLTSサービスが有償ユーザ専用であるという事実を見過ごしている。従って将来的には,Java 8(Java 12がリリースされれば11)用の無料(free-as-in-beer)サポートサービスだけが,Red HatやAmazon,AzulSystem,およびマルチベンダでコミュニティ主導のAdoptOpenJDKプロジェクトなどから提供されるようになる。

今後OracleJDKの無償アップデートがコミュニティで利用できなくなることで,Javaアプリケーションの運用プラットフォームとしての選択が,OpenJDKへ急速に移行するのではないかと思われる。

サーバサイドアプリケーション(と数を増やしつつあるデスクトップアプリケーシ)にとって朗報なのは,OpenJDKがOracleのJDKをそのまま置き換え可能であることだ。

予測: 2019年末には,Java 8とJava 11両方の実行環境の50パーセント以上が,Oracle JDKではなくOpenJDKを使用するようになる。

Java 12のリリース

Java 12は機能フリーズがすでに完了しており,2019年3月のリリースが予定されている。大きなインシデントの発生しない限り,遅れることはないだろう。

Java 12は長期サポートリリースではないので,(Java 9と10がそうであるように)広範に採用されることはないと思われる。

予測: Java 12は予定通りリリースされるが,2019年末に実運用環境にデプロイされる数は誤差範囲に留まる。

Java 13のリリース

Java 13は2019年9月のリリースが予定されている。現時点で,このリリースをターゲットにする機能の詳細は発表されていない。

Java 12と同じく機能リリースであり,LTSリリースではないので,現時点では,予定通りリリースされないと想定する理由は何もない。同じように,運用環境のJava 11への移行を重視する開発チームに対して,広く採用されることはないだろう。

予測: Java 13は予定通りリリースされるが,2019年末に実運用環境にデプロイされる数は誤差範囲に留まる。

Value TypesはJava 13のプレビューには含まれない

Value Types(値型)は,プリミティブ型とオブジェクト参照に続いて,JVMに第3の基本的な値を導入しようという取り組みである。この概念は,Javaの型安全性を完全に維持しながら,Javaの型システムのルールを部分的に緩和することによって,Bagを使わずにCの構造体により近いデータ構造の構築を可能にするもの,と考えられる。

Java言語のアーキテクトであるBrian Goetz氏は,"クラスのようにコードし,intのように動作する"という表現を使って,値型が最終的に提供された場合の一般的な開発者の使用方法について,自身の構想を説明している。

Value Typesについては継続的な進歩が続いているが,2018年末の時点では,実験的かつ極めて早期アクセス的な,対象を専門家に限定したアルファ版のプロトタイプが提供されているに過ぎない。
これは意外なことではない - Value Typesはこれまで実施されたJavaプラットフォームの変更の中でも,最も基本的で根深いもののひとつであるからだ。

この機能の複雑さと野心,必要となる膨大な量のエンジニアリング作業を考えれば,たとえ初期形式であったとしても,2019年内に提供することはとてもできそうもない。

予測: Java 13のプレビュー機能においても,Value Typesが何らかの形で含まれることはない。

Match Expressionの初期バージョンがプレビューとしてJava 13で提供される

Switch Expressionは,Match Expressionの前提条件である。構文としての表現形式なしには,Match ExpressionをJava言語内に展開することは不可能だ。実際のところ,Match Expressionがなければ,そもそもSwitch Expressionを導入する意味はほとんどない。

従って,Switch Expressionが標準化されれば,Match Expressionのシンプルな形式が直後に続くものと期待される。この機能は,当初は型の一致に限定され,非構造化など高度な機能は含まれないと思われる。

予測: 初期段階の限定的な形式のMatch Expressionが,プレビュー機能としてJava 13で提供される。

Kotlinの穏やかな成長

JetBrainsのKotlin言語はここ数年,開発者からの関心を集めるようになった。特にAndroidの分野での普及は爆発的で,Android用の新しいプロジェクトでは優位な立場にある。

しかしながら,JVM言語の伝統的中心地であるサーバサイドでは,これと同じような爆発的人気はない。2019年,Kotkinの採用は徐々に増えていくが,プロジェクトや開発チームが相次いで移行するような状況にはならず,いくつかの有名プロジェクトが構築にKotlinを使用していることを公開するに留まるだろう。

予測: Kotlinは中核的なJavaコミュニティにおいてファンを獲得し続けるが,ブレークスルーには至らず,Scalaエコシステムよりも小さなままである。

ビジネス一般

これまでの説明では,Javaの開発最先端における変更について注目してきた。しかしながら,Java世界の他の部分(Javaの奥地)では,これまでと同じような1年が続くことになりそうだ。JavaのIDE,ライブラリ,その他のエコシステムは,基本的にこれまでと同じ道をたどり続けるだろう。

業界内におけるJavaの確固たる地位と勢いは,大きな問題なく,今後も続くことになるだろう。

予測: 数値化可能な予測は特にない。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

BT

あなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。

Eメールを変更すると確認のメールが配信されます。

会社名:
役職:
組織規模:
国:
都道府県:
新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。