Hatena::ブログ(Diary)

torutkの日記 RSSフィード

2018-03-12

[]Javaの変質、どこに向かうのか

昨年9月にJava SEのメジャーバージョンアップとなるJava SE 9がリリースされました。このJava SE 9のリリースまでは、メジャーバージョンアップがおよそ2〜3年毎に行われてきました*1

しかし、Java SE 9を基点として、今後は半年ごとにリリースする、というタイムボックスの開発・リリースに変わることとなりました。そして、半年ごとのリリースの最初のバージョンとなるJava SE 10が今月リリースされる予定となっています。さらに次のバージョンのJava SE 11は、今年の秋(9月)にリリースされる予定です。

半年毎のリリースがもたらすもの(変質その1)

半年ごとのリリースになるので、従来のメジャーバージョンアップのような大きな変化は少なくなります。なお、Java SE 10の新機能については、久保田祐史氏が次にまとめられている記事が分かりやすいです*2

Java SE 10は、Java SE 9リリースから半年でのバージョンアップ分なので、大きな機能アップはありませんが、ローカル変数の型推論(型名を指定する代わりにvarでローカル変数を宣言)がプログラマーには嬉しい(?)機能でしょうか。

また、半年毎のリリースに伴い、そのバージョンのアップデート提供期間も短くなるのでその対応も発生します。

このあたりは、Java SE 11のリリースで予定されているLTS(Long Time Suppert)版の状況が見えてこないと何とも言えませんが…。

削除されるモジュール(変質その2)

Java SE 9からは、JRE/JDKの内部構造がそれまでの一枚岩(モノリシック)構造から、モジュール構造へと大きく変わりました。モジュールシステム(Java Platform Module System)の導入です。

そして、これまでJavaは互換性堅持が錦の御旗でしたが、モジュールシステム導入と呼応するかのタイミングで、Java SE 11ではいくつかのモジュール(APIとその実装)を削ることになっています。

まず、次です。

JEP 320: Remove the Java EE and CORBA Modules

このJEP 320では、CORBA、JAXB、JAX-WS、JavaBeans Activation Framework、JTAをJava SE 11から削除することが謳われています。

CORBAとJAXBの削除はちょっと悲しいですね。これらを使ったアプリケーションに対する互換性を切り捨ててしまっています。確かにOracleがフォーカスしているクラウドやJavaがそこそこ使われているWebアプリケーション分野ではCORBAの出番は少ないと思います。しかし、制御系システム(○○監視システムとか××制御システムとかいった世界)での機器間の通信では今でも重宝です。制御系で使われる計算機では、OSは商用UNIXから組み込み系/リアルタイム系OS、各種Linux、Windowsと幅広く使われており、CPUもIntel系とは限らず様々なもの、言語は割とC/C++が多いかも、というところです。機器間でOS、CPU、言語が揃っていないので、CORBAが利用できればプロトコル定義、データ定義が楽にしっかりできるのですが、ソケットベースだと超大変です。プロトコルの設計はもちろんのこと、エンディアン変換やアライメント・パディングをしっかり押さえないといけません。

しかし Javaの中でCORBAのライブラリは相当に巨大なので(JDK 1.8.0のrt.jarの中にある約2万クラスのうち1割近くをCORBAクラスが占める)、利用しない大半の人からは邪魔もの扱いされること、OpenJDKを保守していく人からは、利用ケースが少ないのに多大なライブラリを抱え続けるは辛みになるでしょう。ということで、OpenJDKから外してサードパーティーライブラリ*3にゆだねるのは仕方のないことと思います。

JAXBは、単独でも(Java EEを使わない用途でも)使い道がありますが、削除の憂き目にあってしまいます。ユーザーが作成したXMLドキュメントをXMLスキーマで検査しデータクラスとしてアプリケーションで使うのに便利だったのですが・・・。

つづいては、次です。

Java Client Roadmap Update - An Oracle White Paper

Javaクライアントを構成するJava配備機能(AppletsとWeb Start)およびJavaユーザーインターフェイス機能(Swing、AWTとJavaFX)の今後のロードマップについて方針を示した資料です。この資料では、Applets、Web Start、そしてJavaFX をJava SE 11から削除することを謳っています。

@aoetkさんのブログに上述ホワイトペーパーの内容紹介があります。

AppletsとWeb StartはWebブラウザにプラグインする形で動作します。昨今のセキュリティ脆弱性への対処上、存続が厳しくなっていることもあり、既に廃止のアナウンスがでていましたがいよいよJava SE 11からは搭載されなくなります。Webブラウザがセキュリティ脆弱対応でプラグイン機構をなくす方向(HTML5ベースで実現)ということがあるようです。

また、最近のアプリケーションは管理者権限がない一般ユーザーでもインストールできるようユーザー固有の場所にインストールするようになってきています。

Webブラウザのプラグイン機構を使い、システムワイドにJavaをインストール・アップデートする必要があるApplets、Web Startが昨今のセキュリティ事情を含んだ環境になじまなくなってきているのが大きな要因でしょう。

JavaFXは、ホワイトペーパーではクロスプラットフォームなツールキットは、モバイルやWebアプリケーションに侵食されていると書かれています。ですが、クラウドを指向したOracleにとってクライアントは付属物なのでSwingとJavaFXと2つのGUIツールキットの両方を保守するコスト負担を下げるために切り離したのではないかと思います。

さすがにSwingは切れないですし・・・。OpenJFXはOpenJDKにまだ統合できていないので、統合コストも払わずに済みますし。

JavaFXは、独立した方がいい結果になるではと実は期待していたりします。

現状、Oracle内のJavaFX開発リソースはかなり絞られているようで、このままでは逆に立ち枯れてしまうのではとの心配もあります。

JavaFXを使うアプリケーション開発者の観点で、OpenJFX(JavaFX開発プロジェクト)への貢献も、OpenJDK全体の制約が厳しく、例えばバグ管理システムで類似バグがあったので追加情報を登録しよう、と思ってもOpenJDKコントリビュータ−でないとバグ管理システムへの追加登録はできない、などが壁になります。バグがあるのが分かっていて、ソースコードの修正もできる状況で、JDKのクラスに手を入れるのはライセンス違反になる、といったジレンマも生じます。

ということで

Javaは、これまでの互換性護持、ゆっくりとした変化、という性質から、短い間隔で素早い変化、互換性は(これまでに比べれば)トレードオフによる、という性質に変わりつつあります。コンピューティング環境が大きく変化しつつある今日では、この変質は大枠でよい方向と思います。

JavaFXは、OpenJDKに含まれてくれることを期待していましたが、ちょっと残念、ですがOpenJDKから独立することにより開発(保守)が加速する期待があるといったところです。

*1:Java SE 7のときには、ラムダの導入他で紆余曲折があり4年半かかっています

*2:OpenJDK 10の新機能ですが、OpenJDK ≒ Java SEと思っていいかな…

*3:代表的な製品を挙げると、オープンソースのJava用CORBAにはJacORBが、商用製品にはVisiBroker for Javaがあります。