GlassFish の落日

すべての元凶は、これでした。

Java EE and GlassFish Server Roadmap Update

(日本語訳 [Java] Java EE and GlassFish Server Roadmap Update)

この件については皆さん誤解している、という趣旨でいくつかの「声明」がでましたが、あれから2ヶ月が経ち状況は悪化の一歩を辿っています。これについては、現物を見た方が早いですね。

まず、正式リリースであるGlassFish 4.0 build 89より、開発ビルドであるGlassFish 4.0.1 build 3の方が安定動作する時点で、既にどこかおかしいのです。4.0.1 build 4は昨年8月下旬から作業が始まったものの、いまだ完了の目処が立っていません。

それでは、先に触れた「声明」と、それに対する現状をお話ししましょう。

[Java] Java EE and GlassFish Server Roadmap Update

http://orablogs-jp.blogspot.jp/2013/11/java-ee-and-glassfish-server-roadmap.html

GlassFish Server Open Source Edition 4.1は2014年に計画(これまで通り)

筆者見解 > 現在の4.0.1の進捗を鑑みると、この計画はほぼ実現不可能です。

必要に応じて、GlassFish Server Open Source Editionに対するアップデートを計画している。これは商用サポートされないものである。

筆者見解 > 現在計画されているアップデートはv4.0.1のみで、しかも事実上頓挫しています。商用サポート以前の問題です。

(Java EE 8に向け、)トランクは最終的にJava EE 8実装としてのGlassFish Server Open Source Edition 5へと移行する。

筆者見解 > これは現時点では正しい情報です。

(Java EE 8に向け、)Java EE 8参照実装はGlassFish Server Open Source Edition 5をベースとして導出する。これは過去のJava EEとGlassFish Serverリリースでやってきたことと同じである。

筆者見解 > これも現時点では正しい情報です。

Oracleは今後、商用サポート付きのOracle GlassFish Serverの将来のメジャーリリースをリリースしない。具体的には、Java EE 7の商用サポート付きのOracle GlassFish Server 4.xはリリースされない。

筆者見解 > これが私たちに突きつけられた過酷な現実です。

商用Java EE 7サポートはWebLogic Serverから提供される。

筆者見解 > やれるものならやってみろ!

Oracle GlassFish Serverは4.xの商用バージョンをリリースしない。

筆者見解 > これが意味することは、Oracle自身がGlassFishへの人的リソース配分を大幅に減らすということです。そしてその分のリソースはWebLogicにシフトされるはずです。

Java EE標準に基づいて開発されたアプリケーションはGlassFish ServerおよびOracle WebLogic Serverにデプロイできる。

筆者見解 > Javaの原理原則に従えば、そういうことになるでしょう。しかし、現実はそこまで甘くありません。

GlassFish ServerとOracle WebLogic Serverには実装固有のデプロイメントディスクリプタの相互運用性がある。

筆者見解 > この「相互運用性」は問題を抱えており、基本的に互換性はないものと考えるのが適切です。

GlassFish Server 3.xとOracle WebLogic Serverはかなりの量のコードを共有しており、そのため設定や(拡張)機能に類似点がかなりある。共有しているコードにはJPA、JAX-RS、WebSockets (いずれもJSR 356以前のもの)、CDI、Bean Validation、JAX-WS、JAXB、そしてWS-ATなどがある。

筆者見解 > GlassFish 3.xとWebLogic 12cのコード共有について下表にまとめてみました。「かなりの量のコードを共有している」というのが嘘であることがお分かり頂けるかと思います。下表には載せていませんが、GlassFishとWebLogicではカーネルを含む基盤部分の設計が全く異なります。

GlassFish と WebLogic の実装比較表
機能GlassFishWebLogic補足
JPA EclipseLink TopLink JPA の範囲のみコードを共有する
JAX-RS Jersey Jersey WebLogicのJerseyは旧バージョンで深刻なバグあり
WebSocket Grizzly 独自実装 コードは共有していない
CDI Weld Weld WebLogicのWeldは旧バージョンで深刻なバグあり
Bean Validation Hibernate Validator Hibernate Validator コードを共有する
JAX-WS Metro Apache Axis 2 コードは共有していない
JAXB MOXy/JAXB-RI JAXB-RI GlassFishではMOXyが優先使用され、実質的にコードは共有していない
WS-AT Metro Apache Axis 2 コードは共有していない

Oracle GlassFish Server 3.xおよびOracle WebLogic Server 12cは共にOracle Access Manager、Oracle Coherence、Oracle Directory Server、Oracle Virtual Directory、Oracle Database、Oracle Enterprise Managerをサポートしており、基礎となるOracle JDKへのサポートを得る権利がある。

筆者見解 > これは事実です。ただし、GlassFish 4以降にこれが引き継がれないことが問題なのです。

まとめると、OracleはJava EEの将来にコミットしています。Java EE 7がリリースされ、Java EE 8の計画が始まりました。

筆者見解 > 「Java EE」の将来に対してコミットしているのは間違いないでしょう。ただし、「GlassFish」の将来にコミットするとは一言も触れていないことに注意が必要です。

GlassFish Server Open Source Editionは引き続き、今後のJava EE参照実装の戦略的基盤としてあり続けます。

筆者見解 > GlassFishは今後もJava EEのリファレンス実装であり続けることは、想像に難くありません。しかし、単にリファレンス実装としての役割を果たすだけであれば、GlassFishのアプリケーション・サーバとしての機能の大部分は不要です。

そして開発者に対し、必要に応じてアップデートを提供し、GlassFish Server Open Source Editionのすばらしい開発者体験を提供する予定です。

筆者見解 > 「予定」という言葉を軽々しく使って欲しくないものです。「必要に応じて」とはOracleの判断によるものであり、OracleがGlassFishを軽視しているのであれば、クリティカルな問題であってもスルーされる可能性があることを、私たちは心に留めておかなければなりません。

2013年11月5日付け 寺田佳央 @yoshioterada 氏のツイート

GlassFish 自身がなくなるわけでは決してありません。

筆者見解 > GlassFish という製品がなくなることは決してないと思います。私も寺田氏も、GlassFish への思いは変わらないはずですから、いよいよ危ないとなった時には私も寺田氏もそれなりのアクションを起こすだろうと思います。

GlassFish は Java EE の参照実装 OSSプロダクトとして今後も残ります。

筆者見解 > これについては、現時点では何とも言えません。オープンソース化したプロダクトは、その気になればいつでもクローズドソースに出来るという前例は、OpenSolarisが作ってしまいました

定期アップデートも提供予定です。

筆者見解 > これは現時点となっては嘘です。多分、日本オラクルの上の方からそのように広報するように言われているのでしょう。現状、定期アップデートどころか、随時アップデートも不可能な状態です。

Java EE and GlassFish Server Roadmap Updateについて

http://yoshio3.com/2013/11/05/glassfish-commercial-unsupport/

先のツイートの補足として寺田氏のブログに投稿された記事です。

GlassFish v4 以降の商用サポートを終了する発表もなされました。ここでご注意頂きたいのは、GlassFish という製品自身や OSS のプロジェクトがなくなるわけでは決してありません。
 (※ また、GlassFish v3.1.x 系のサポートは Extended Support まで含めると 2019/03 まで継続提供されます。)
 (補足:GlassFish v4.0 用は OSS 版のみが提供されており商用サポート製品 Oracle GlassFish Server は提供されていませんでした。)

筆者見解 > これは重要な事実です。慌てる前にまずこの一節をしっかり読み込んで理解してください。

GlassFish は今後も Java EE の参照実装 OSSプロダクトとして残りますし、必要に応じて バグ FIXなどのアップデートも提供予定です。実際 GlassFish v4.1を来年リリースする予定で動いております。

筆者見解 > 現在、GlassFish Communityには、バグFIXなどのアップデートを提供する余力がありません。GlassFish 4.1については、具体的な計画自体が存在しません。現状を見る限り、GlassFish 4.0.1もGlassFish 4.1もリリースの目処が立っていません。

また、今後も Java EE の参照実装として提供されるのは GlassFish で、Java EE の最新機能をいち早くお試しいただけるのも GlassFish です。

筆者見解 > 表向きは正しいですが、GlassFish 4.0 GAはJAX-RS周辺を中心に致命的なバグを多数抱え、Java EE 7の仕様通りに動作しません。

商用サポートの観点で、GlassFishは今後商用サポートの提供は行われず、WebLogic 側で提供します。サポートの観点で、契約を結んでいただいたお客様に対して提供していた製品個別のお問い合わせや、パッチの提供は GlassFish v4.0 以降 行いませんが、OSSとしてバグ登録パッチ提供等は今後もできます。

筆者見解 > 一応、Oracleのサポート・ポリシーは守りますよ、ということです。

またテクニカルの面ではJava EE準拠アプリケーションの場合、WebLogicとGlassFishは配備記述子レベルで互換性を持たせるよう実装していますので、WebLogicへの移行は容易です。GlassFishで開発、テストを実施しWebLogicへ配備といった事も可能になります。

筆者見解 > 嘘を言うな!

つまり、無償で利用可能な OSS Tomcat の代わりに OSS版 GlassFish を使用していた方には殆ど影響は無いと想定しますし、今後も Tomcat に対し Java EE の参照実装として優位点、機能的優位点は代わりません。

筆者見解 > Tomcatにはサードパーティのサポートが多数存在しています。一方でGlassFishのOSS版をサポートしているベンダーは皆無です。いかにTomcatが機能的に劣っていたとしても、サポートが付いている以上、保守的に凝り固まっている日本企業はTomcatを選ぶことでしょう。

OSS版GlassFishを商用サポートがあるから、将来に備え無償でご利用されてきた方は、開発時、テスト時は GlassFishをご利用いただき、商用サポートが必要になった時点で WebLogic などをご検討いただければ誠に幸いです。

筆者見解 > そのようなケースでは、初めからOTNライセンスのWebLogicで開発しないと、後で痛い目を見ます。GlassFishユーザーをなだめるつもりだったのでしょうが、世の中そんなに甘くありません。

最後に、少なくとも私は今後も、Java EE 関連のセミナーにおいて、デモの実行環境として、もしくはJava EE の機能説明に参照実装としての GlassFishを使用しますし、それを止めなさいとはオラクル本社から一切言われておりませんし、その位置づけは変わっておりません。Java EEの参照実装であり、OSS製品としての GlassFish は今後も啓蒙活動で使用してまいります。

筆者見解 > この件については、私も同意見です。私はWebLogic Server勉強会で登壇することが度々あるのですが、実は技術検証とサンプル作成はGlassFishで行っており、後でWebLogicで動作するように修正しています。最近では手抜きのため、デモを堂々とGlassFishで行うケースもあります。

WEBLOGICをGLASSFISHの商用版として使う方法

http://www.mushagaeshi.com/2013/12/06/glassfish-to-weblogic/

筆者にとつては不愉快きわまりないタイトルですが、書いてあることはまともなので一読の価値はあるかと思います。とはいうものの、突っ込みどころはあるので、少しだけですが取り上げてみます。

GlassFishの開発元であるOracleは、商用版Java EE準拠サーバーとして、WebLogic (ウェブロジック)を販売し続けています。古くからJ2EEを触ってきた人にはご存じのサーバーであり、Java EEサーバーの世界シェアNo.1、デファクトスタンダードと言われているものです。

筆者見解 > これについては一概には言えません。集計結果によってまちまちで、JBossやGlassFishの後塵を拝し、しかもWebSphereよりもシェアが小さいという情報もあったりします。

WebLogicにはFaceletだけではなく、Backing BeanやEJBなどが、再配備せずとも自動的に画面に反映してくれる「Fast Swap」があります。例えば画面を書き換える場合、JSF Faceletを書き換えて、Backing Beanやその他Javaのファイルも書き換えると思うんですが、GlassFishの場合、Facelet以外を反映するためには再配備が必要になります。ところが、WebLogicのFast Swapはこれが必要ないんですね。NetBeansで書き換えて保存して再実行したら即時反映してくれます。実際の開発作業はこれが無いと結構やってられないので、現実の近代的なエンタープライズ開発現場には必須の機能です。

筆者見解 > こういった独自機能は、ベンダー・ロックインを促進するだけで、Java本来のポータビリティを失うトリガーとなります。個人的にはFast Swapは使用しない方が良いと思っています。

WebLogicのEJB周りの仕様は2001年-2004年辺りで実装されたものが延々と使われ続けている経緯があり、初期化タイミングからリモートインタフェースの挙動、あとはWebLogic独自の(WebLogicのWebLogicたる所以でもある)T3プロトコル周りまで含めて、結構GlassFishと異なります。なので、この辺りをGlassFishの挙動をアテにしていたら、結構裏切られることが多く、最悪プログラムの修正も必要でしょう。

筆者見解 > これはかなりの問題ではありますが、最近の風潮としてRMI-IIOPやCORBAの代わりにJAX-RSをリモート・コンポーネント呼び出しに使用することが多く、いずれどうでも良いことになるでしょう。

最も違う特徴的な面は、Production Redeploymentという、古いアプリを動かしながら新しいバージョンのアプリを再配備するという、アクロバティックな機能です。これは24時間ノンストップ運用のために必須でありますが、結構きわい挙動もたまにあり、常に安定して動作させるためには現場の知見の蓄積が必要です。

筆者見解 > Production Redeploymentは100%の確率でメモリリークを発生させますProduction Redeploymentはメモリリークを完全に防ぐことができない問題があり、当該機能ありきでの運用は好ましくないと考えます。詳しい仕組みは昔 @nekop 氏に教わったのですが、ほとんど忘れてしまいました。ただ、当時の私の理解によると、Production Redeploymentを使用する場合は新旧アプリケーションについてそれぞれクラスローダーが生成されるのですが、旧アプリケーションのクラスローダーを解放するタイミングが判定できずそのままメモリ空間上に残り残ることがあり、Production Redeploymentの繰り返しによってやがてヒープメモリを食いつぶしてアプリケーション・サーバがダウンするに至ります(これはWebLogic固有の問題ではなく、Java VM仕様の不備によるものだとか)。Production Redeploymentを使用する場合には、必ず計画停止のスケジュール調整とセットで行うべきだと考えます(そもそもProduction Redeploymentなんてベンダー・ロックインを誘導するような機能を使うべきではないのですが)。

(訂正)以下のことです。筆者の記憶違いと当時の理解不足でした:

他にも英語の「声明」はいくつも出ているのですが、ここでは割愛します。

ちなみに、GlassFishの将来に関わる件でOracle関係者に問い合わせをすると、OCA承認済みの筆者であっても、「貴方が知る必要はない!」とものすごい剣幕で怒られます(具体的に誰とは言いませんが)。GlassFishの将来は、このままでは「実用的サーバ」から「新機能を試すためおもちゃ」に成り下がります。あるいは、「WebLogic Lite」のようなリファレンス実装向け製品が現れ、GlassFishが潰されてしまうかもしれません。少し時間がかかっても構わないので、どうにかしてGlassFishを本来の姿のまま維持できないか、模索している今日この頃です。