今年はすっかり登録を失念しており、急いでこの日にねじ込みました。EEアプリケーションをOne-JAR化する」でした。いう感じの一年でした。EEの、企業システムの基盤としては正しい状況だと思います。一方で日進月歩のダイナミズムという観点だと、何となく物足りない感じもします。みんな麻痺してる気もします。余談ですが、実際の企業システムを開発・運用・管理している側からすると、ちょくちょく仕様が変更になるのは全く迷惑以外の何者でもありません。仕様追加ならば許容範囲内ですが、変わっちゃうと既存システムの互換性が問題になりますので。EE仕様の場合はよっぽど古いので無ければ切り捨てられる事も少ないですので、この点は良いですね。2016でありました。2016毎度ではありますが、国内報道はこの一部の側面しか流れませんので、参加されてない方は何が起きているのか理解不能なのではないかなとも感じます。参加しないと理解出来っこない、というのは仮に米国内に居たとしても同じ状況ではあると思いますので、永遠の課題ではあります。日本の場合、参加費用がカンファレンス参加費約20万円に加え、渡航滞在費が4-50万円くらい余計にかかる、しかも参加出来たとしても、英語が聞けて話せないと参加費約20万円をドブに捨てる形になってしまいます。EE愛好家の鏡とも言える行動かと思います。ひとつ一念発起して頑張って世界に出て行く方々を応援したいと考えております。今後頑張るとしても今年の状況は分からないと思いますので、私の見聞きした範囲を公開出来る範囲で記録として残しておきます。大人の事情で全部書けるわけでは無いので、そこはまあ、そういう話としてご理解を賜りますようお願い申し上げます。EE仕様策定は今後どうなるのか?ここらへんの話は英語の一次情報を得ている人は気付いてる人は気付いてると思いますが、あまり掘り返してもいいことは無いので、目先を変えて今後どうなるのか、という話です。EEの仕様策定は相変わらずOracleによって先導されます。これ自体は、強力にホスティングしている会社が居ないとグチャグチャに空中分解することになるので、全く問題無いと思います。Oracleが好きかどうか、というのは全く別問題なのでそれは別の機会に。そこへの意見としては、透明性を高めて欲しいという要望は当然ながら出ている訳でして、スペックリードへは諸々の要望が出ている状況です。それも正常なプロセスの一環であるため、特にこれと言って変わりはありません。JPE(はどうだったか正確には知らないですが)やJ2EEの昔からそういう意見が出て、諸々改善されてきました。改善されてないものもあります。面白くない(?)結論ですが、まあ、そういう状況である事には変わりないでしょう。少なくとも、何かが大きく変わることは無さそうです。EE仕様は今後どうなるのか?次。8仕様は元々もう少し早い時期に出る予定でしたが、ほぼ唐突に延期と仕様変更案がJavaOneで出てきました。2016JCP周りのプロセスで問題があるとすれば、この辺りが閉鎖的に見えてしまう点となるでしょう。EEの仕様自体が複数の仕様で構成される巨大仕様であるが故に、個別の話は個別の仕様内に閉じてしまう事と、その悪影響か全体仕様を見ている人があまり多くない印象です。いうことで、あくまで案ではありますが、仕様変更案が出て、それに伴う投票が10月に締め切られました。私も投票するようTwitterで繰り返し呟きました。これに対する文句がある場合は、もう遅いという状況のため、投票しなかった方は「後出しジャンケン」(=後で文句ダラダラ)は無しにて呉々もお願い致します。締め切りが10/21なので、それまで投票を。投票せずに後から文句言うのはルール違反。建設的に進めましょう。ここを履き違えると誰も幸せになれない。2016と、公開しようと作業をしていたら、続報が。投票結果が出ていました。今回外された3つは見事に最下位から3つでした。「結果は残酷」としか言いようが無いかなと。8が策定されることがほぼ既定路線となり、既にjcp.org内にてこの結果を受けての作業が進行中ですので、今度はその中身を見ていくことにしましょう。(revised)というのが通称ですが、まあ日本人に分かりやすく以下「改訂版」としときます。改訂版ではCloud対応に焦点が当たりまして、その観点で見直しが入ったという形になります。「という建前になっている」、と補足をしたほうがいいかもしれませんが・・・。EE規格策定が結構ノロノロであるため、その間に世の中の方がCloudバンザイの方向に行っちゃってしまいました、なので急ぎ対応させます、という感じで捉えると、然程間違いないかと思います。8仕様はこんなものを含んでました。2.0が、改訂版はこうなりました。(new!)私自身としては、脱落した仕様はほとんど使ってなく、使う予定も無かったため、ほぼ影響無しで済みそうです。これらを当てにしていた方々からすると、やり場の無い怒りをどうしてくれよう、という感じかもしれません。EE方面に熱を上げてる方面はかなり限定されるとは思いますが・・・まあ、そんな感情論はさておき、落ち着いて変更点をひとつずつ見ていきましょう。7のJMS仕様のまま、改定しない、という話になります。一部で廃止なのか!?と盛り上がりましたが、それは勘違いです。9に恐らく載ることになります。今回は仕様バグの小修正のみが取り込まれる模様です(バージョン番号は不変)。2.1での大きな追加要素は、非同期バッチ仕様が追加となり、アノテーション定義が拡張されて@JmsListernerが追加され、CDIでJMSが使えるようになる、等々というものでした。Beanが不要になる、という、CDI愛好家方面が狂喜しそうな内容が主だったところのため、微妙ちゃぁ微妙な更新でした。延期の理由を関係者に直接聞きましたが、要は「作業する人が少ないので、人員を別の重要な更新に集中させるため」となります。個人的にもこれはあんまり重要で無い気がするので、延期で良いかと。なんてことを書くと他の関係者の恨みを買いそうですが(笑)。(引き下げ)これは悲劇ですかね。1.0というのは要はStrutsの後継というか、Strutsを今どき風に格好良くして標準化したようなものだった、とざっくり考えれば良いかと思います。EE仕様のWeb標準フレームワークは、ページ駆動型のJSFです。これは紛れもない事実。要はASP.NETのASPXと同じようなものです。あるため、2000年代に流行したアクション駆動型のStrutsからの移行は「ほぼ作り直し」という非常に高いハードルを要求されます。これの救済策として急浮上したMVC仕様でした。Strutsを狙った多くのセキュリティーホールが出てきた頃に焦点が当たった経緯があるため、要はそういうトレンドに乗っかって出てきた感じではありました。ところが急にスポットライトを浴びたものは飽きられるのも早い訳でして、今年のJavaOneではいきなり無かったことになってました。2014年・2015年のJavaOneでの狂騒は一体何だったのか。延期の理由も関係者に聞いたところ「もはや重要ではないから」とバッサリ一刀両断でした。8仕様から落ちるのは大賛成です。実はこの仕様を期待していた日本国内のベンダーやら顧客は多かった、と風の便りに聞くわけでして、さてどうなることやら。「既存のStrutsコードが大量だから移行なんて無理無理」とかゴネるのも、もう限界だと思います。(引き下げ?)これはサーバー管理APIですね。JMXとかMBeanとか関連と思ってもらえれば。1.1′′で2006年改訂ですから、もはやカビが生えた感が強いですが、これをRESTベースに書き換えましょうというのがオリジナルプランでした。仕様から落ちるのは、「クラウド時代に注力するのはここじゃないよね」(意訳)というものなので、ある程度しょうがないかな。RESTベースに変更は既存のアプリケーションサーバーに膨大な仕様変更を強要する事になるので、そりゃぁ各方面が嫌がるでしょうね。EEに載るのかは不明です。更新されず将来廃止されるかもしれません。そっちが濃厚な気がします。(new)次は逆に追加されたものを見ていきましょう。