QCon New York 2017: SpeedmentのJava 9マイグレーション

Speedment CEOのDan Lawesson氏が、今年のQCon New York 2017 Conferenceで、"Migrating Speedment to Java 9"という講演を行なった。取り上げられた話題は次のものだ。

• Speedmentの概要
• Jigsawの概要
• SpeedmentのJava 9マイグレーションについて

Speedment

Lawesson氏はまず、データベースアプリケーション開発用のオブジェクト-リレーションマッピング(ORM)ツールであるSpeedmentを紹介し、コンパイル時コード生成ツールを使った既存のデータベースへの接続と、Java 8ストリームを使ったクエリの構築方法について説明した。

Lawesson氏の説明によると、データベースアプリケーションの構築において、従来のORMアプローチには２種類の命令的アプローチが使用されている。すなわち、明示的なSQL文とJavaストリームである。それに対して、Speedmentは完全に宣言的で、JavaストリームがデータベースとJVMオペレーションの両方を表現しており、実行時に処理の分担が決定される。

Speedmentはオープンソース版とエンタープライズ版で提供されている。バージョン3.0リリース以降の新機能として、ユーザ入力に基づいたMavenプロジェクトを生成するユーティリティのInitializerがある。

Jigsaw

Lawesson氏は、Project JigsawあるいはJSR 376としても知られるJava Platform Module System(JPMS)で導入された、信頼性の高いコンフィギュレーションの重要性について論じた。"信頼性の高いコンフィギュレーション"とは、パッケージを単一モジュールに限定しなければならない、という意味だ。下図に示すように、複数のモジュールに分割されていてはならない。

Lawesson氏はまた、自動モジュールによってJava 8からJava 9への移行がスムーズになる一方で、モジュールパスがクラスパスに依存するため、パッケージの分割が発生することについても論じた。遅延ロード、動的なパッケージ、パッケージ分割の可能なOSGiとJigsawは根本的に異なるものである、というのが氏の説明だ。

Speedmentの"Jigsaw化"

Speedmentは現在、それ自体のコードをJava 9に移行中である。Speedment Open Sourceでは、Speedmentがサードパーティライブラリやサポート外のAPI、あるいはsun.misc.Unsafeなどに依存しないため、マイグレーションは比較的容易だ。氏は、移行のためのスクリプト作成プロセスについて、詳しく説明した。

• すべてのモジュールを含むディレクトリを別に作成する
• 各ソースコードパッケージをそれぞれのモジュールに移動する
• 空のmodule-info.javaファイルを追加する
• その後は、通常のsdlcループを実行する
  • コンパイル
  • 解析と修正
  • git add
  • git commit

Speedment Open Sourceのマイグレーションが比較的容易である一方、Speedment Enterpriseでは、サードパーティ製ライブラリとsun.misc.Unsafeを利用していることが問題になる。

Lawesson氏はSpeedmentと、SpeedmentをJava 9に移行する上での課題への対処方法について、InfoQに説明してくれた。

InfoQ: 他のJava ORMフレームワークと比較して、Speedmentはどのような点がユニークなのでしょう？

Lawesson: おもに２つあります。完全に宣言的なStream APIであることと、ユーザアプリケーションを変更する必要なく、フレームワーク内でクエリの高速化が可能なことです。Speedmentは純粋なJava Stream APIを使用して、データベース内のデータで何を(what)行なうかを記述する、宣言的なアプリケーションコードを実現しています。それを実現する方法(how)は、Speedmentフレームワークに任されます。従って、Speedmentを利用するアプリケーションには、クエリ言語を含む必要はありません。オフヒープメモリデータストアを使用して、Speedmentが透過的にクエリを高速化してくれます。

InfoQ: Speedment EnterpriseをJava 9に移行する際の問題に対して、どのような対処を計画していますか？

Lawesson: 現在見つかっている問題に関して言えば、解決はそれほど難しくありません。ロードマップには載せていますが、現在は顧客のプロジェクトや新しいコア機能の開発に深く関わっているので、Jigsawでモジュール化されたSpeedmentプラットフォームに完全に移行するには、まだ数ヶ月かかりそうです。

InfoQ: プレゼンテーションで、"現在のMavenはOSGiバンドリングやJigsawとはうまく共存できない"と述べていましたが、InfoQでは1年ほど前に、OSGiとJigsawの相互運用性を取り上げた2部構成のシリーズを公開しています。OSGiとJigsawの相互運用性について、あなたの考えを聞かせてください。

Lawesson: 私の発言は、概念的な分析ではなく、MavenプロジェクトをコンパイルするためにOSGiバンドルを無効にしなければならなかった事実を踏まえた上での、実践的な経験を共有することが目的でした。講演でも述べたように、私たちの時間は限られていますから、そのうち他の誰かが間違いなく解決してくれるような問題の回避には、必要以上に時間をかけないことにしたのです。OSGiバンドリング用のMavenプラグインは、私たちがテストを行なった当時、Java 9では正しく動作しませんでした。これは明らかに、そのような問題のひとつです。

一般的な解釈として、OSGiとJigsawを同一プロジェクト内に持つことに、概念的な問題は何もありません。ただし、Jigsawの厳格な拘束性は、OSGiを導入することによって失われます。これはただ、OSGiが本質的に動的であるためです。例えば、単一のクラスローダ内のJigsawシステムを完全に信頼できるように構成することは、別々のクラスローダに分離されたバンドルを持つ動的なOSGi設定では実現できません。OSGiのバンドルとJigsawのモジュールは異なる概念であり、違う問題の解決を目的としたものだからです。

Speedmentプラットフォームは依存関係をそれほど多く持っていないので、JDK自体がそうであるように、Jigsawの厳密なモジュール化とは相性がよいのです。しかし、私たちがOSGiをサポートする理由は、内部的なコード構造よりも、ユーザに対するサービスとしての意味の方が常に大きいのです。あなたがあげた記事にも取り上げられていたような、Jigsawに関する広範な概念から判断するならば、この件については今後も長く考慮すべき点として残ると思います。

InfoQ: オリジナルのJSR376の投票で、Speedmentはどのような投票をしましたか？

Lawesson: 個人的な意見として、Jigsawのような根本的かつ非互換的な変更には、将来的なユーザベースの断片化を回避するためにも、コミュニティのコンセンサスが不可欠だと思います。ですから、5月初めの投票では、反対票("望んでいない"ではなく、"まだその時期ではない"という意味で)が正しい判断でした。

InfoQ: 今後の計画について教えてください。

Lawesson: 現在は新しいトランザクションのサポートと、より効率的な集約の実装に取り組んでいます。EurekaとRibbonとの統合改善によるクラスタソリューションへの対応も、現在開発中の機能のひとつです。コードベースの完全なJigsawモジュール化もロードマップ上にありますが、現在着手できているものはありません。

InfoQ: あなたがSpeedmentに加わって何年になりますか？現在の役割についても教えてください。

Lawesson: ちょうど1年になります。チーフサイエンスオフィサとして、開発やアーキテクチャ、テクニカルライティング、セールスサポートを行なっています。