BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Java EE 8に対する長いトンネルの終わりに光が当てられた

Java EE 8に対する長いトンネルの終わりに光が当てられた

原文(投稿日:2017/04/14)へのリンク

Java EE 8への長いトンネルの終わりについに光が当てられたのかもしれない。オラクルは直近のブログ投稿でJava EE 8への活動におけるJavaコミュニティを更新した。これは最新のリリーススケジュールを含んでいる。

  • パブリックレビュー: 2017年4月/5月
  • 最終ドラフトの提案: 2017年6月
  • 最終リリース: 2017年7月

2017年2月21日のJava EEのスペックリードLinda DeMichiel氏からJSR 366 (Java EE 8)エキスパートへのeメールはスペックリードがどのように今後の意欲的なスケジュールについていき、Java EE 8の最終リリースで対象としているJSRを完了させるのかについて要点を述べている。

MVC 1.0仕様(JSR 371)の指揮権は最近オラクルから移され、Java EE 8には含まれないこととなった。

Kevin Sutter氏は、IBMのJava EEアーキテクトであるが、DeMichiel氏へのeメールでサーブレット4.0のALPN(アプリケーション層のプロトコルネゴシエーション。“hello”メッセージ交換の内側にあるプロトコルネゴシエーションを含むTLS拡張。Java SE 9に含まれる予定である)への要求がどのように解決されるのかについて質問した。DeMichiel氏はこう返答した。

このサポートをJava SE 8へバックポートすることについて、議論が続いていることを知っています(もしくは、少なくとも必要なAPIを)。しかし、私はまだ何も公式には見ていません。ここで*何か*をする必要があります。現在設計されているものとしては、仕様は現時点では壊れています。

Java EE 8への道は簡単ではない。この1年Java EE 8へのオラクルの取り組みに関して多くのことが書かれた。手短には、2013年のJava EE 7リリースのあと、オラクルはJava EE 8への計画に関して情熱を表明していた。JavaOne 2013のテーマは“Javaの将来を作る”と付けられた。2013年11月のブロク投稿で、オラクルは次のように述べた。

Java EE 7とGlassFishサーバのオープンソース版4のローンチのあと、私たちはJava EE 8のロードマップを計画し始めました。これはJavaOneのストラテジーキーノートでもカバーされています。要約しますと、HTML5サポートとクラウドへの改善とNoSQLサポートの研究に多くの関心があります。私たちはJava EE 8に入れてほしいものについて、多くのすばらしいフィードバックをコミュニティと顧客から受け取りました。

 

要約すると、オラクルはJava EEの未来を約束した。Java EE 7はリリースされJava EE 8への計画が始まった。

同じブログ投稿内で、オラクルはまたOracle GlassFish Serverに対する商用サポートに関して大きな変更を公表した。

オラクルは商用サポートのあるOracle GlassFish Serverの新規メジャーリリースをもうリリースしません。具体的にはJava EE 7の商用サポートがあるOracle GlassFish Server 4.xはリリースしません。

 

既存の商用Oracle GlassFish Serverの顧客がOracle WebLogic Serverへの移行を計画し始めることをオラクルは推奨します。技術的に、そしてライセンスとしても自然なマイグレーションパスは次のようなものです。

しかしながらGlassFish Serverのオープンソースへのサポートは継続する。

2014年9月に、新たに作られたJava EE 8仕様(JSR 366)で最初のリリーススケジュールが提案された。

  • エキスパートグループ設立: 2014年第3四半期
  • アーリードラフト: 2015年第1四半期
  • パブリックレビュー:2015年第3四半期
  • 最終ドラフトの提案: 2015年第4四半期
  • 最終リリース: 2016年第3四半期

しかしそれからオラクルの情熱は弱まってきたように見えた。2015年6月のブログ投稿で、オラクルはJavaコミュニティを更新した。

それから私たちが自身に設定したゴールはこの作業をJavaOne サンフランシスコ 2016までに完了させることです。私たち全員がJavaOneで大きなことをしたい(そして聞きたい)のですが、エキスパートグループの立ち上げを含むさまざまな遅延と他のことが私たちのスペックリードの時間を要求したことで、日程が少し後ろにずれる結果となりました。私たちはJava EEプラットフォームへの作業への透過性に強く取り組みます。それゆえに私たちは今この作業の完了期限を2017年の上半期に変更することを公式に発表します。

この遅れは元オラクルのエヴァンジェリスト、Reza Rahman氏がJava EEガーディアンズとして知られるコミュニティ組織を立ち上げる原因となった。これはものごとを正しい方向にすることを目的としている。InfoQは2016年6月にレポートしている。

昨年のオラクルのGlassFishサーバの将来のメジャーリリースの停止とサポートの制限についての以前の発表に続いてJavaのエヴァンジェリストを削減した結果、Java標準の伝承者のグループ、彼らは自身をJava EEガーディアンズと呼んでいますが、Java EEを救いに来たという彼らの意図を宣言しました。

 

Java EEガーディアンズはJavaの名士の真の人名録です。“Javaの父”James Gosling氏や元エヴァンジェリストReza Rahman氏、その他を多くのJava技術者を含んでいます。

同時期に他の新しいグループMicroProfileは、レッドハットIBMTomitribePayaraの協業で“ベンダ中立のマイクロサービスフレームワークを作るためにJava EE技術に投資する”ために、形成され、認可された。2016年9月までに最初のリリースをすることを目標としている。

Java EEガーディアンズとマイクロプロファイルコミュニティによる活動はオラクルの注目を集めているように思える。2016年7月のInfoWorldの記事に以下のようにある。

Java EEの未来に対するオラクルの意図ははっきりしない。控えめに言っても。

 

プロジェクトは後回しにされるとうわさされているが、オラクルはエンタープライズJavaの管理をめぐる不平の嵐を切り抜けてきた。2つの別々の組織はオラクルなしでJava EEを前に進める計画を考えている。Java EEを弱らせるよりむしろ、オラクルは代わりにエンタープライズが進む場所、とくにクラウドをよりよく収容できるプラットフォームへ再始動することを目指している。これは最近の批判への返答においてオラクルの地位の高い人が言っている。

そしてInfoQは2016年8月にこのように記事にしている

InfoWorldでの最近のインタビューにおいてThomas Kurian氏は、氏はOracelの製品開発の責任者であるが、Java EE 8に向けて計画されている要改善点を発表した。この動きは次のようなことを意図していると信じられている。最近の批判を抑えること(批判とはたとえばJava EEガーディアンズから来ているもののようなものだ)と分岐する影響を抑えることだ(分岐とはたとえばMicroProfileのようなものだ)。現在の声明は単なる意図の宣言のように見えるが、より詳細はJavaOne 2016で明らかにされるだろう。

 

Java開発コミュニティは、今年の5月にJCP Executive CommitteeにオラクルにJava EEへのコミットメントと計画について公の返答を要請する公式な動きを出すことを考慮するように至るまで、Java EEの将来についてますます関心を持っている。 この動きは承諾されなかったが、会議の議事録に記録されている。このことはその動きを実質的に非公式な動きに変わらせた。それからおよそ1ヶ月後change.orgの要請がJava EEガーディアンズによってオラクルにJava EEにおけるボールを落とさないことへの勧めが提出された。署名者は3300人ほどだった。

2016年9月、オラクルはJCP Executive Committeeと戦略を共有した。InfoQは記事にしている

Anil Gaur氏は、Java EEとWebLogicサーバに責任を持つオラクルのグループヴァイスプレジデントだが、直近のJCP Executive CommitteeミーティングでJava EEの将来についていくらか光を当てるために話すように招待された。彼のメッセージは先のオラクルからの声明に沿うものだった。エンタープライズのプログラミングは変化している。そしてオラクルはそれに適応することを望んでいる。しかしながら、ECのメンバーからのその後の質問は、計画でのギャップを強調するものだった。

 

Thomas Kurian氏が、氏はオラクルでの製品開発責任者だが、約6ヶ月前にJava EEのトピックについてインタビューされたあとに、オラクルがJava EEのトップに戻ってくる主導権が明白になった。この文脈において、Gaur氏はオラクルのJava EE戦略についての口頭によるプレゼンテーションを、直近の8月9日のJCP ECミーティングの期間に提供した。 彼のプレゼンテーションにおいて、Gaur氏はますます多くのアプリケーションが分散アーキテクチャに追従していることとともに、どのようにエンタープライズのプログラミングが変化しているかをオラクルが理解していることを示した。この結果として、Gaur氏はそれが明白な利益をもたらすように、一連の技術がJava EE 8に追加されることが望まれているということを強調した。Kurian氏のインタビューのものととても似通っているように思われるリストを提供している。HTTP/2と設定、状態管理、結果整合性、マルチテナント、O-Auth、OpenID接続である。しかしながら、Steve Wallin氏は、IBMのランタイム技術のプログラムディレクタであるが、IBMが現在のJava EEプラットフォームをベースに急速なクラウド開発をなんとか達成したことを認めつつも、短い期間でそのような革命的な変化が必要とされることについて疑問を投げかけている。(おそらくBluemixを言及している)

 

しかし、おそらく情報のもっとも興味深い部分は、言われなかったことにある。口頭のプレゼンテーションのあと、Executive Committeeのメンバーはより深く理解するために質問をした。いつ新しいバージョンが利用可能となるのかということだった。Gaur氏はJava EE 8のリリース日が"変更され"詳細は教えられないことを認めた。けれども、いくつかの新しい機能がJava SE 9をベースにするかもしれないというヒントはかなり長期の遅れとなることを指し示しているだろう。

JavaOne 2016で明らかにされたことは、Java EE 8のリリースがマイクロサービスとクラウドアプリケーションのためのサポートを含むために2017年末までさらに遅れることだった。計画はJava EE 9のリリースが1年後となることを含んでいる。

またJavaOne 2016の期間中、Registerが次のことを記事にした

10のJava EE 8プロジェクトは今開発とデプロイにおいて普及している動向に対処するための“重大な拡張”を経ている。改訂はBean ValidationとCDI、JAX-RS、JSF、JSON-P、Servletに影響する。

 

Java EE 8へのこの直近の延期に理由はないが、オラクルは今年開発プロセスの間に職務離脱するところを引き止められた。エンジニアとスペックリードは彼らの一連のコードコミットが大幅に減る間、Javaコミュニティの他のメンバーとのコミュニケーションをやめた。オラクルは引っ張り上げられ、Javaへまだ注力していると主張する声明を出すことを強いられた。

 

Java EE 8は分散データストリームやHTTP/2、キーバリューペア、OAuthとOpenIDコネクトシステムを使ってキーを管理するために使う標準メソッドをサポートし、どんな単一のコンテナにおいても1つ以上の成果物をまとめられるようDockerをサポートするだろう。そして統一されたイベントモデルやサービスにおけるトランザクションとマルチテナントを管理するための整合性をサポートするだろう。

 

コーディングを単純化する手助けとして、Java SE 8のラムダはJava EE 9になる。Java EE 8に入らなかった機能はJava EE 9へ繰り越されるだろう。

 

オラクルは現在コミュニティメンバーにJava EE 9にあるとよい機能を教えてほしいと尋ねている。

オラクルは開発者にJSR活動への貢献を勧めることを継続するものとして2つめのAdopt-a-JSRウェブキャストを投稿した。

ガートナー

ガートナーは2016年11月に発表したレポートでJava EEの集結を予測した。レポートの要約は次のようなものだ。

アプリケーションプラットフォーム市場はデジタルビジネス要求に対応して変化している。Java EEと他の3層フレームワーク、たとえばASP.NETだが、関連において勢いがなくなったため、アプリケーションリーダはクラウドネイティブなアプリケーションをサポートする代替のプラットフォームへ移行する戦略を構築しなければならない。

このレポートはReza Rahman氏やKito Mann氏、Josh Juneau氏、Ryan Cuprak氏を含む何人かのJavaの著名な技術リーダと論争を引き起こした

Java EEベンダ

レッドハットPivotalのようなベンダ、彼らは開発においてコアなJava EE仕様を使っているが、Java EE 8の遅れに対処することを強いられた。InfoQが2016年7月に記事にしたように、Spring 5のリリースはサーブレットAPI4.0を含まない。Oliver Gierke氏、PivotalのSpring Dataのプロジェクトリードだが、Jaxenterに話したとき、彼は次にように説明した。

私たちにとって、Java EE 8においてもっとも重要な側面は、サーブレットAPI 4.0がHTTP 2.0をサポートすることです。次のことがある意味では予測できます。それは、Spring 5をGAからリリースするまでにサーブレットAPI 4.0が最後までいかないだろうということです。私たちは現在サーブレットコンテナの実装(TomcatやJetty、Undertow)と密接に近づいて仕事をしています。これは、まず第一にそれらのネイティブAPIを使ってHTTP 2.0のサポートを提供できるかを確かめるためです。

Jason Greene氏、レッドハットのJBoss EAPのプラットフォームアーキテクトであるが、2016年10月にInfoQに語った。Java EE 8とJava 9の遅れがWildFlyWildFly SwarmJBoss EAPの将来の開発にどのように影響するかを尋ねたとき、彼はこう説明した。

WildFlyとJBoss EAPはともにEE標準を超えて進み、絶え間なく進化しています。仕様の遅れが発生したとき、私たちは単に他の興味深い分野に焦点を当てるだけです。とは言っても、私たちは標準が業界と同じペースを保つ方がよく、なので私たちはマイクロプロファイルの開発において他の主要なプレーヤとと協力する方が幸せです。

Resources

 
 

Rate this Article

Relevance
Style
 
 

この記事に星をつける

おすすめ度
スタイル

BT