企業における Java は今後どこへ向かうのでしょうか?

コンテナ、マイクロサービス、サーバーレス 新しいスタイルのエンタープライズ ソフトウェア開発サークルで大流行する可能性があります。 Gartner は宣言した可能性があります Jakarta Enterprise Edition (JEE)、旧名 J2EE がレガシー プラットフォームに、しかしそれ以上 最も人気のある Web サイトの 10% は依然として JEE を利用しています.

もし エクリプス財団、現在 JEE の将来を指揮しているグループには独自のやり方がありますが、 JEE はクラウド内で存続する可能性がある. 古いプログラマーに新しいトリックを教えることができます。

JEE を Oracle から Eclipse に移行するのは簡単ではありませんでした。 エクリプス財団のエグゼクティブディレクターであるマイク・ミリンコビッチは次のように書いています。 Eclipse Enterprise for Java (EE4J) 最上位プロジェクトが作成されました、39のプロジェクトが設立されました。 まだすべてのソース コードが移行されていませんが、着実な進捗状況を確認してください。 プロジェクトステータスページ."

それでも、EE4J は未来に目を向けることを止めませんでした。 ミリンコビッチ氏は、JEE 開発者への調査に基づいて、EE4J プロジェクト管理委員会が「 JakartaEE のストローマン技術ビジョン コミュニティのレビューとフィードバックのために。」

言い換えれば、Java の企業の将来に関するこのビジョンは、明確に定められたものではありません。 現在進行中の作業です。

まず、EE4J が望んでいることは、 JEE をクラウドネイティブ Java プラットフォームに変換する. 一般に、「Jakarta EE の使命は、より頻繁にリリースし、参加の障壁を下げ、コミュニティをプラットフォームに戻すことです。」

これらはすべて歓迎すべき変更となるでしょう。 Java プログラマーは、Oracle が Java コミュニティ プロセス (JCP). 理論的には、JCP は、Java の企業所有者である Sun と Oracle とともに開発者が主導権を握る、オープンソース方式のようなものであるはずでした。 実際には、企業がショーを運営しました。 Eclipse では、開発者も発言権を得ることができます。

それはこのロードマップから始まります。 ミリンコビッチ氏は、プログラマーに対し、この最初の草案にただ同意するのではなく、ロードマップの設定に協力するよう奨励している。

だからといって、企業が発言権を持たないというわけではない。 そうするだろう。 新しい JEE の最初のメンバーである Oracle、IBM、Red Hat に加えて、他の企業も参加しています。 新しい JEE メンバーには、富士通、Payara、Tomitribe Microsoft、Pivo​​tal、SAP が含まれます。

将来を見据えて、EE4J が実現したいこと ドッカー コンテナ、 Istio サービス メッシュ, Kubernetes コンテナオーケストレーション、および NoSQL データベースを JEE に変換します。 これらは「開発者がポータブルなクラウドネイティブ アプリケーションを作成できるように、プラットフォームの新しいバージョンにすぐに採用される」予定です。

EE4J はまた、JEE の準備を整えたいと考えています。 Java9. 最初のバージョンは依然として Java 8 に基づいています。

他の古いプログラミング フレームワークやツールは、より早く廃止される予定です。 たとえば、 Ant ビルド システム Java の事実上の標準ビルド システムに置き換えられます。 メイビン. 他のプログラムも廃止が検討されます。

委員会が述べているように、「多くの採用者にとって、下位互換性は常に Java EE の強みでした」 しかし同時に、他の人にとっては弱点でもあり、特にそれはしばしば社会のペースを遅らせるように見えるため、 革新。 下位互換性を必要とするユーザーが、多くの場合何年も下位互換性を信頼できるようにする方法が必要です。 他の企業は、以前のバージョンの Jakarta EE との互換性を無視して、より迅速なリリースを進めることができます。」

EE4J はまた、開発者がハード依存関係ではなくソフト依存関係を使用することを好みます。 つまり、世界の半分に依存しているコンポーネントはマイクロサービス開発には適していないため、コンポーネントの使用を阻止しているということです。 代わりに、プログラマは「プラットフォームの一貫性を維持しながら、ユーザーがアプリケーションに必要な機能だけを組み込めるようにするモジュール型アプローチ」を使用する必要があります。

JEE の技術リーダーも「テストはあらゆるプロジェクトの非常に重要な部分である」と考えています。 したがって、「仕様と API は、それを使用するアプリケーションが簡単にテストできるように設計される必要があります。」

これは、使用できる JEE プログラムと連携して機能します。 ジェンキンス 継続的インテグレーション。 とはいえ、いくつかのプロジェクトはすでに使用しています トラビス-CI, しかし、Eclipse は Jenkins を好みます。

最後に重要なことですが、JEE は毎年リリースされる予定です。 コンポーネントの場合、推奨は年 3+1 の頻度で、1 つのメジャー リリースがプラットフォーム リリースと同期され、四半期ごとに 3 つのマイナー リリースが行われます。

ですから、私があなただったら、JEE を帳消しにはしないでしょう。 Java はクールではないかもしれませんが、これらの変更と、3 層アプリケーション フレームワークからクラウド ベースのモデルへの変換を待っている大量のレガシー プログラムを考慮すると、JEE は私たちよりも長生きする可能性があります。

関連記事:

• さようならJEE、こんにちはジャカルタEE
• オラクルはJava EEをEclipse Foundationにスピンオフする準備をしている
• Java EEユーザーはより多くのRESTを必要としていることが調査で判明