BT

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

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Java EE 8の停滞、Javaコミュニティは重要か?

Java EE 8の停滞、Javaコミュニティは重要か?

ブックマーク

原文(投稿日:2016/07/09)へのリンク

オラクルのJava EEへの取り組みが遅れていることに対して、多くの関心が寄せられている。 InfoQがJava EEガーディアンズについての話を驚くべきこととして伝えた後、Pivotal所属のSpring DataプロジェクトのリーダでありJPA 2.1のエキスパートグループであるOliver Gierke氏が最近次のことをJaxenterに向けて話した。Java EE 8に対してオラクルが明らかに興味を失っていることと、とりわけJavaコミュニティへの潜在的影響とについて話をした。

Java EE 7のリリースから数ヶ月後、2013年の11月にオラクルからJava EE 8のロードマップについてのアナウンスのブログ投稿があった。

Java EE 7とGlassFishサーバのオープンソースエディション4のローンチ後、私たちはJava EE 8のロードマップを計画し始めました。これは、JavaOneのストラテジーキーノートの内容をカバーしています。要約すると、次のようなことに大きな関心があります。HTML5のサポートの改善とクラウド、NoSQLサポートへの投資です。私たちはコミュニティや顧客から、Java EE 8にあるとよいものについてたくさんのすばらしいフィードバックを受け取っています。

要するに、オラクルはJava EEの未来にコミットしています。Java EE 7をリリースし、Java EE 8への計画を開始しました。

その後、このブログ投稿にあるオラクルが記述した情熱は、停滞してしまったように見える。2015年6月のオラクルによるブログ投稿は、Java EE 8のロードマップについてJavaコミュニティへ情報を提供している。

2016年にサンフランシスコで開催するJavaOneでこの作業を完了させることが、次に私たちが自分自身に設定したゴールでした。 私たち全員がJavaOneで大きなことをなし(そして聞き)たいですが、エキスパートグループを開始するにはさまざまな待ち時間が含まれます。これは結果として日付を少し遅らせてしまうような時間を、スペックリードが要求する場合と同様です。 Java EEプラットフォームへの私たちの取り組みをはっきり見えるようにすることに、私たちは強くコミットしています。それゆえに私たちは公式に次のことをアナウンスします。私たちは今、この作業を完了する目標期日を2017年上半期に変更します。.

Java EE 7のリリースから2年後、オラクルはJavaコミュニティにもっと長く待つ必要があると伝えた。Java EE 8の状況について質問すると、Gierke氏は次のように言った。

全体的に見て、Java EE 8はJava EE 7ですでにいくぶん明らかになったストーリを基本的に継続しています。参加団体は興味がなくなってきているように見えます。 私の意見では、これは次の事実によるものです。主要な団体はすべてクラウドの活動に焦点を当てています(オラクルはOracle Cloud、レッドハットはOpenShift、IBMはBluemix、そう、PivotalはCloud Foundryです)。

Josh Juneau氏は、、JSR 372JSR 378のエキスパートグループのメンバーだが、2016年4月のブログ投稿に彼の考えを寄稿している。ある調査の後、Juneau氏は次のことを知った。オラクルに所属していないスペックリードがリードするJSRは、オラクルのスペックリードがリードするJSRよりもよりアクティブであるということだ。また、(以下に示すように)JSR 372へのコミット数が急激に落ちていた。2015年10月以降Javaコミュニティがほとんどの作業を完了させている、とJuneau氏は述べた。 すなわちZEEFの共同設立者でリードディベロッパであるArjan Tijms氏と、共同設立者でwebアプリケーションスペシャリストのBauke Scholtz氏である。

graph

Paul Krill氏、氏はInfoWorldの全体の編集者であるが、氏の最近の記事において、James Gosling氏がオラクルでとても“不安にさせる”ことを発見したと記述している。

オラクルのEEへの干渉はそれほど多くありませんが、コミュニティとの協力においては干渉しています。それを“所有”しているように、非標準な人気があるモデルが“一度入ったら出られない捕獲器”へ向かうように。“顧客はチェックインしますが、彼らはチェックアウトしません”。

Spring 5とJava EE

JavaOne 2010の記事でKrill氏はJava EEのパネルセッションを記述した。ここでは、話し合いがSpring対Java EEという議論へそれた。

“私は決してJava EE 6にSpringを入れません。なぜならSpringはあまりにも重なりあうものだからです。”とAdam Bien氏は述べている。氏はコンサルタントであり、著者であり、講演者である。SpringとJava EEのアノテーションを両方使うことは複雑になる結果となります、と彼は言っている。

“ほとんどのプロジェクトにとって、私の個人的な意見は単独のものだということです。SpringかJava EE 6かのどちらかです。”とBien氏は述べた。しかしながら、開発者はEE 6の上にSpringのユーティリティを使うことができるとBien氏は言う。

しかし、Reza Rahman氏は、2つの技術セットの間での競争にストレスを感じている。Rahman氏はCaucho Technologyのリードエンジニアである。“Java EEはSpringを必要としています。Springも同様にJava EEを必要としています。”とRahman氏は述べた。

ほぼ6年後、Gierke氏の評価はRahman氏が述べたことと類似している。Rahman氏は現在CapTech Venturesのコンサルタントでオラクルの元Java EEエヴァンジェリストである。

伝えられるところでは、SpringとJava EEの関連は競争によって影響力を持つように特徴づけられています。しかしもっとよく見れば、すぐに次のことがわかるでしょう。そこにはいつも相互に影響があった(または今もある)こと、そして、はっきりと白と黒にわかれているというよりは、グレーの色合いがたくさんあることです。

その一方で、いくつかの領域では基本的にSpringはJava EE仕様の上に構築されています。ゆえにSpringはJava EEを必要とします。Spring MVCは現在の形態ではサーブレットAPIなしでは考えられません。他方、フレームワークはもっとも重要な仕様をつねにサポートしてきました。

SpringはサーブレットAPIに依存しているとすでに述べたが、Spring 5の初期リリースはサーブレットAPI 4.0を含んでいない。Gierke氏は次にように説明する。

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

Javaコミュニティは重要か?

2015年6月、オラクルはブログ投稿でJavaコミュニティの手助けを奨励した。

このシフトの結果、今あなたにとって参加する時間と機会はより増えました。

開発者が個々のJSRのメーリングリストやwikiを見てJSRの動きを追いフィードバックを提供すること、Java EE 8の早期参照実装ビルドをダウンロードして試すことを、私たちは引き続き奨励しています。私たちはすでにJava EE 8の機能だけでなく関与へもたくさんの興味があることを知っています。

しかし、2015年9月にKrill氏は記事で次のことを主張している。InfoWorldは元オラクルの地位のある従業員からEメールを受け取った、と。このEメールから引用すると、次のようにある。

オラクルは競合に権利を与えることに興味はなく、イノベーションを共有したいとも思っていません。

この会社はJava EE(エンタープライズエディション)を縮小していますが、これはまたJavaやJava EEに誰も従事してほしくなく、JCP(Java Community Process)を脇に追いやっています。“彼らは勝者総取りのメンタリティを持っており、共同作業には興味がありません。”

Eメールでは次のことを提案している。JCPメンバーはオラクルの顧客に公開書簡を送る、ということだ。これは彼らにJavaに起こっていることを警告するためだ。オラクルはどんな"Javaファウンデーション"とも決して協業しないでしょうし、そのIP(知的財産)を手放さないでしょうう、と。

より最近の記事で、Juneau氏はなぜJava EEを前に進めることが重要でそれを消させないかを説明している。

はっきりと言うと、安全なままにしておくため、今日現在のAPI技術を使うためにこれらの技術は前に進める必要があります。もしJava EEを停滞させることを単に望むなら、これは次のことを意味します。Java EEのすべてまたは一部を使っているアプリケーションとサービス(ご存知のとおりインターネットの大半です)もまた停滞するということです。そして技術やセキュリティの関心事を現在のままにし前に進めることができません。

Gierke氏はJava EE 8を取り巻くコミュニティの活動が増加していることに満足しています。しかし、彼は次のように警告しています。

私が考えるに1つの側面があります。それはむしろ露出不足ということであり、実際にはやや危険です。Java EEの周辺に実際に集まるメンバーのうち、何人が完全に中立でしょうか。ライセンスの理由のせいで、オラクル主導のJSRに対して私たちができることは何もありません。

しかし、あなたがオラクルとの法的なやり取りに巻き込まれるのをいとわなくなるまで、そうしたことはすべて何も解決できないでしょう。Googleとともに見てきたストーリーを考慮すると、これは誰かが巻き込まれたいと思っていると、私が確信しているわけではありません。それゆえに、実際それがなかった時にけしかけるのも奇妙なことだと私は思います。

Java EEガーディアン

今年初めの彼のオラクルからの旅立ちのあと、Rahman氏はJava EEを前に進めるためにJava EEガーディアンを作った。とりわけ、

  • Java EE 8を広める
  • Java EE 8のJSRをサポートする
  • Java EE 8へのコミットメントを果たさせるようにオラクルにロビー活動をする
  • 活動していないオラクルのJSRを他のベンダーに移す機会を探る

Java EEガーディアンは、オラクルがJava EE 8での進捗がないことの証拠を提供し、Larry Ellison氏に届けるつもりである嘆願書にサインすることをJavaコミュニティに勧めている。InfoQは記事でこのトピックにおける長い議論が生じていることを知らせた。

Gierke氏はオラクルはJava EE 8への興味を失っていると述べ、彼の考えをまとめている。

もしそれほど広く大きな影響でないなら、現在の状況に少し皮肉を見つけてしまうでしょう。Springスタックは以前私有のものとみなされていました。なぜなら開発がまったくの1社だったからです。けれどもやや楽観的ではありますが、Java EEスタックはつねに完全にオープンでコミュニティ主導でした。単に1つの会社が興味を失っただけで、今エンタープライズのJavaの世界は混乱しています。

 
 

Rate this Article

Relevance
Style
 
 

この記事に星をつける

おすすめ度
スタイル

BT