Java EE Advent Calendar 2016 の 12/22 分となります。今年はすっかり登録を失念しており、急いでこの日にねじ込みました。昨日分は @TTakakiyo さんの「WebSphere LibertyでJava EEアプリケーションをOne-JAR化する」でした。
さて、Java EEの今年の動きは予想通りさほど大きくなく、どちらかと言うとJava EE 7が着実に企業システムに拡がっていったのかな? という感じの一年でした。それはそれで実業務を担うべく誕生したJava EEの、企業システムの基盤としては正しい状況だと思います。ただ、一方で日進月歩のダイナミズムという観点だと、何となく物足りない感じもします。みんな麻痺してる気もします。
余談ですが、実際の企業システムを開発・運用・管理している側からすると、ちょくちょく仕様が変更になるのは全く迷惑以外の何者でもありません。仕様追加ならば許容範囲内ですが、変わっちゃうと既存システムの互換性が問題になりますので。Java EE仕様の場合はよっぽど古いので無ければ切り捨てられる事も少ないですので、この点は良いですね。
話を元に戻しまして、ダイナミズムの観点では次期仕様であるJava EE 8について、数多くの動きが今年のJavaOne 2016でありました。
Beautiful San Francisco time ! #JavaOne pic.twitter.com/iVs4FH8RKK
— 岩崎浩文 / 武者返し.com (@HirofumiIwasaki) 2016年9月19日
毎度ではありますが、国内報道はこの一部の側面しか流れませんので、参加されてない方は何が起きているのか理解不能なのではないかなとも感じます。参加しないと理解出来っこない、というのは仮に米国内に居たとしても同じ状況ではあると思いますので、永遠の課題ではあります。
日本の場合、参加費用がカンファレンス参加費約20万円に加え、渡航滞在費が4-50万円くらい余計にかかる、しかも参加出来たとしても、英語が聞けて話せないと参加費約20万円をドブに捨てる形になってしまいます。大変高いハードルです。
Good morning! pic.twitter.com/Hq0AdtGkye
— 岩崎浩文 / 武者返し.com (@HirofumiIwasaki) 2016年9月18日
とはいえ、ここは仕様策定している有名人達と仲良くなるために頑張って英会話とライティングを習得し、あらゆる手段を使ってJavaOneに参加する、そして仕様策定に影響を及ぼす、というのがJava EE愛好家の鏡とも言える行動かと思います。ひとつ一念発起して頑張って世界に出て行く方々を応援したいと考えております。
ただ、今後頑張るとしても今年の状況は分からないと思いますので、私の見聞きした範囲を公開出来る範囲で記録として残しておきます。勿論大人の事情で全部書けるわけでは無いので、そこはまあ、そういう話としてご理解を賜りますようお願い申し上げます。
1. Java EE仕様策定は今後どうなるのか?
ここらへんの話は英語の一次情報を得ている人は気付いてる人は気付いてると思いますが、あまり掘り返してもいいことは無いので、目先を変えて今後どうなるのか、という話です。
"Java EE for the Cloud [BOF7984]", I believe this BOF is the super important for the #JavaEE specs. #JavaOne pic.twitter.com/7tzOSZsA6Y
— 岩崎浩文 / 武者返し.com (@HirofumiIwasaki) 2016年9月20日
Java EEの仕様策定は相変わらずOracleによって先導されます。これ自体は、強力にホスティングしている会社が居ないとグチャグチャに空中分解することになるので、全く問題無いと思います。Oracleが好きかどうか、というのは全く別問題なのでそれは別の機会に。
そこへの意見としては、透明性を高めて欲しいという要望は当然ながら出ている訳でして、スペックリードへは諸々の要望が出ている状況です。が、それも正常なプロセスの一環であるため、特にこれと言って変わりはありません。Project JPE(はどうだったか正確には知らないですが)やJ2EEの昔からそういう意見が出て、諸々改善されてきました。改善されてないものもあります。普通です。
面白くない(?)結論ですが、まあ、そういう状況である事には変わりないでしょう。少なくとも、何かが大きく変わることは無さそうです。
2. Java EE仕様は今後どうなるのか?
次。問題はここです。オリジナルのJava EE 8仕様は元々もう少し早い時期に出る予定でしたが、ほぼ唐突に延期と仕様変更案がJavaOneで出てきました。
#JavaEE loadmap #JavaOne pic.twitter.com/yexw4iqFRs
— 岩崎浩文 / 武者返し.com (@HirofumiIwasaki) 2016年9月18日
JCP周りのプロセスで問題があるとすれば、この辺りが閉鎖的に見えてしまう点となるでしょう。Java EEの仕様自体が複数の仕様で構成される巨大仕様であるが故に、個別の話は個別の仕様内に閉じてしまう事と、その悪影響か全体仕様を見ている人があまり多くない印象です。
ということで、あくまで案ではありますが、仕様変更案が出て、それに伴う投票が10月に締め切られました。私も投票するようTwitterで繰り返し呟きました。これに対する文句がある場合は、もう遅いという状況のため、投票しなかった方は「後出しジャンケン」(=後で文句ダラダラ)は無しにて呉々もお願い致します。
For Japanese engineers: 締め切りが10/21なので、それまで投票を。投票せずに後から文句言うのはルール違反。建設的に進めましょう。ここを履き違えると誰も幸せになれない。呉々もお願い致したく。 https://t.co/ka3GCzo73p
— 岩崎浩文 / 武者返し.com (@HirofumiIwasaki) 2016年9月30日
と、公開しようと作業をしていたら、続報が。投票結果が出ていました。今回外された3つは見事に最下位から3つでした。まあ「結果は残酷」としか言いようが無いかなと。
Java EE 8 – Community Survey Results and Next Steps https://t.co/sB13j570LC #JavaEE #JSR366
— David Delabassée (@delabassee) 2016年12月21日
いずれにせよ、この改定仕様にてJava EE 8が策定されることがほぼ既定路線となり、既にjcp.org内にてこの結果を受けての作業が進行中ですので、今度はその中身を見ていくことにしましょう。
3. 改訂版Java EE 8では何が変更になったのか?
Java EE 8 (revised)というのが通称ですが、まあ日本人に分かりやすく以下「改訂版」としときます。改訂版ではCloud対応に焦点が当たりまして、その観点で見直しが入ったという形になります。「という建前になっている」、と補足をしたほうがいいかもしれませんが・・・。
いずれにせよ、Java EE規格策定が結構ノロノロであるため、その間に世の中の方がCloudバンザイの方向に行っちゃってしまいました、なので急ぎ対応させます、という感じで捉えると、然程間違いないかと思います。
"Java EE 8 Update [CON7976]" #JavaOne pic.twitter.com/8B8gbPZcWc
— 岩崎浩文 / 武者返し.com (@HirofumiIwasaki) 2016年9月19日
オリジナルのJava EE 8仕様はこんなものを含んでました。
- JMS 2.1
- JCache 1.0
- JAX-RS 2.1
- JSON-B 1.0
- JSF 2.3
- MVC 1.0
- CDI 2.0
- Java EE Security 1.0
- JSON-P 1.1
- Servlet 4.0
- Java EE Management 2.0
が、改訂版はこうなりました。
JMS 2.1 (延期)- JCache 1.0
- JAX-RS 2.1
- JSON-B 1.0
- JSF 2.3
MVC 1.0 (脱落)- CDI 2.0
- Java EE Security 1.0
- JSON-P 1.1
- Servlet 4.0
Java EE Management 2.0 (脱落)- Health Checking (new!)
- Configuration (new!)
私自身としては、脱落した仕様はほとんど使ってなく、使う予定も無かったため、ほぼ影響無しで済みそうです。が、これらを当てにしていた方々からすると、やり場の無い怒りをどうしてくれよう、という感じかもしれません。そんなにJava EE方面に熱を上げてる方面はかなり限定されるとは思いますが・・・
まあ、そんな感情論はさておき、落ち着いて変更点をひとつずつ見ていきましょう。
3-1. JMS 2.1 → JMS 2.0 (延期)
これはJMSが廃止になるとかそういう話でも何でも無くて、Java EE 7のJMS仕様のまま、改定しない、という話になります。一部で廃止なのか!?と盛り上がりましたが、それは勘違いです。ただの延期。JMS 2.1はJava EE 9に恐らく載ることになります。今回は仕様バグの小修正のみが取り込まれる模様です(バージョン番号は不変)。
JMS 2.1での大きな追加要素は、非同期バッチ仕様が追加となり、アノテーション定義が拡張されて@JmsListernerが追加され、CDIでJMSが使えるようになる、等々というものでした。これによりEJB Message-Driven Beanが不要になる、という、CDI愛好家方面が狂喜しそうな内容が主だったところのため、微妙ちゃぁ微妙な更新でした。
延期の理由を関係者に直接聞きましたが、要は「作業する人が少ないので、人員を別の重要な更新に集中させるため」となります。個人的にもこれはあんまり重要で無い気がするので、延期で良いかと。なんてことを書くと他の関係者の恨みを買いそうですが(笑)。
3-2. MVC 1.0 (引き下げ)
これは悲劇ですかね。MVC 1.0というのは要はStrutsの後継というか、Strutsを今どき風に格好良くして標準化したようなものだった、とざっくり考えれば良いかと思います。
Java EE仕様のWeb標準フレームワークは、ページ駆動型のJSFです。これは紛れもない事実。要はASP.NETのASPXと同じようなものです。であるため、2000年代に流行したアクション駆動型のStrutsからの移行は「ほぼ作り直し」という非常に高いハードルを要求されます。これの救済策として急浮上したMVC仕様でした。主にStrutsを狙った多くのセキュリティーホールが出てきた頃に焦点が当たった経緯があるため、要はそういうトレンドに乗っかって出てきた感じではありました。
ところが急にスポットライトを浴びたものは飽きられるのも早い訳でして、今年のJavaOneではいきなり無かったことになってました。2014年・2015年のJavaOneでの狂騒は一体何だったのか。
延期の理由も関係者に聞いたところ「もはや重要ではないから」とバッサリ一刀両断でした。個人的にも、元々古くさいMVC仕様がこのタイミングで何故出てきたのかさっぱり理解出来なかったので、誤解を恐れずに言えば、EE 8仕様から落ちるのは大賛成です。
実はこの仕様を期待していた日本国内のベンダーやら顧客は多かった、と風の便りに聞くわけでして、さてどうなることやら。「既存のStrutsコードが大量だから移行なんて無理無理」とかゴネるのも、もう限界だと思います。もう諦めて、現代的なJSFで作り直す方がいいと思いますよ・・・
3-3. Java EE Management 2.0 → J2EE Management 1.1 (引き下げ?)
これはサーバー管理APIですね。JMXとかMBeanとか関連と思ってもらえれば。旧仕様が”J2EE Management 1.1″で2006年改訂ですから、もはやカビが生えた感が強いですが、これをRESTベースに書き換えましょうというのがオリジナルプランでした。
仕様から落ちるのは、「クラウド時代に注力するのはここじゃないよね」(意訳)というものなので、ある程度しょうがないかな。RESTベースに変更は既存のアプリケーションサーバーに膨大な仕様変更を強要する事になるので、そりゃぁ各方面が嫌がるでしょうね。これは次のJava EEに載るのかは不明です。更新されず将来廃止されるかもしれません。そっちが濃厚な気がします。
3-4. Health Checking (new)
次は逆に追加されたものを見ていきましょう。二つです。
まずは監視。これは上記3-3のJava EE Management 2.0の代替としての位置づけ感が強いですね。強烈に違うポイントとしては、こちらはマイクロサービス(自走JARアプリケーション)を前提にした新APIである点です。マイクロサービス仕様はJava EE 9で登場する予定と聞いていますので、完全にそれを狙ってるのでしょう。
Serverless #JavaEE proposal. Big changing #JavaOne pic.twitter.com/Cs38jmxPyO
— 岩崎浩文 / 武者返し.com (@HirofumiIwasaki) 2016年9月18日
いずれにせよ、これ以上細かい情報が出てない気がするので、これはちょっと判断待ち状態かと思います。どこかに出てるのかな。知ってる人居たら教えて下さい。
3-5. Configuration (new)
次に設定系の新APIです。これは完全にクラウド環境における可搬性を向上させる目的で、設定を読んだり更新したりできるものでしょう。
Java EEでは、初版であるJ2EE 1.2から設定は読み取り専用でXMLファイルで定義するものでした。いわゆるDeployment Descriptor。これがJSON等に対応し、動的に更新出来るようになるものなのか、それとも凶悪に旧式のPropertiesクラスを置換する目的になるのか、いまいちよく分かりませんが、いずれにせよこの辺りのものを置換するものと考えるのが良いでしょう。
ここら辺の周辺系改善は個人的に大賛成なので、どんどん新しいものを導入して現場の管理スタイルを洗練させて欲しい所であります。管理コストも下がるでしょうし、精神衛生上も良くなります。何より、不要なプロジェクト内共通ライブラリーを作らずに済みます。
4. JavaOne 2016について
最後にJavaOne 2016について纏めておきましょう。
2014年・2015年とスピーカーとして参加しましたが、今年は上記の混乱からか選考から外れてしまいました。私だけ?と思っていたら、あらあらあの人もあの人も・・・と。要はJava EE 8を狙ったセッションは悉く外されてしまった模様です。残念。去年のJavaOne 2015ではJava EEでのBatch設計・実装の話をしました。
Great talk by @aforarsh and @HirofumiIwasaki on Batch Processing #JavaOne2015 pic.twitter.com/y0hI9jHKVz
— Rodrigo Troy (@RodrigoTroy) 2015年10月28日
このため、JavaOne 2016のJava EEセッションの多くは、上記の改訂版Java EE 8の中身を説明するものに多くが費やされていた感触を得ました。まあ、それはそれで良いでしょうと、今年は久しぶりにリスナーとして参加することになりました。自分が話すための準備が無かったので、だいぶのんびりと参加させてもらいました。
With @reza_rahman and @yoshioterada on Moscone. Thanks for the great time! #JavaOne pic.twitter.com/yfRVThxUFR
— 岩崎浩文 / 武者返し.com (@HirofumiIwasaki) 2016年9月19日
とはいえ、個別に多くの方と個別ミーティングを持たせてもらったことと、普通にフラフラ歩いてたら「あららこんにちは」系の脱線も多くあり、網羅的にセッションに参加出来た訳ではありません。勿論、そこから全然別の話に繋がったりと、むしろそこがJavaOne等海外カンファレンス参加の醍醐味なのでありまして、当然ながらそういう嬉しいハプニングを優先させています。
※なので、英語を聞けて喋れないとお金と時間をドブに捨てることになるのです。内容を見聞きするだけなら、YouTubeの中継を見とけばいいですしね。
現場で感じたこととしては、Java EE 8が延期されたのでイマイチ盛り上がりに欠ける状況ではあり、スペックリードが登壇するセッションも人が少な目、という微妙さ・余所余所しさが昨年以上あり。恐らくUS在住の方も日本以外在住の方も、今回はネタが少ないため参加を見送った方が多数あったのではないかと思います。
ただ、その分「一見さん」は減った感じがあり、何が何でも参加する方面の方々の毎年見る顔が揃いに揃った、という、Java EEマニアからするとレア度満点な感じも受けました。そこで会話される内容が久しぶりに濃く、私としては満足な参加となりました。
#JavaEE keynote sumamry #JavaOne pic.twitter.com/4mzIvcTY0A
— 岩崎浩文 / 武者返し.com (@HirofumiIwasaki) 2016年9月18日
あまり難易度の高い話とメンバー固定化はオープン環境としてはイマイチかとは思いますが、そもそも取り扱っている題材が高難度のものであるが故、それに相応しい議論が行われるべきですし、ここはある程度許容範囲かと思います。そんなにマニアックなこと、誰でも込み入って会話出来る訳でも無いですしね。
ここは参加したセッションによって感触が左右されると思いますので、あくまで私個人が受けとった感触ということにて。来年のJavaOne 2017が待ち遠しいですね! 来年はこれら改訂版Java EE 8に則った、リファレンス実装であるGlassfish 5をダウンロード出来るようになっていることでしょう(勿論出ます)。
"James Gosling with the Newest, Latest, and Cutting-Edgiest Technologies with Free and Open Source Tools" #JavaOne pic.twitter.com/A98jRgXDvq
— 岩崎浩文 / 武者返し.com (@HirofumiIwasaki) 2016年9月18日
明日の回は @gishi_yama さんとなります。