「EEには常に代替手段があります」-Java EE / EE4JについてのDmitry Alexandrov（T-Systems）

最近、 Java EEに関して多くの話題がありました。最初は8番目のバージョン、次にEclipse Foundationへの移行と名前の変更のニュースです。 しかし、多くのニュースの議論は、新しい名前のEE4Jについて人々が考えるものにまで及びます。 私たちはこれに限定しないことに決め、 Dmitry Alexandrov （T-Systemsの有力なエキスパートプログラマー）に尋ねました。彼は仕事でJava EEを扱い、EEコミュニティで活動しており、会議でEEレポートを作成しています。 そこで、「あなたの仕事への適用可能性」の観点と「コミュニティ全体の考え」の観点の両方から、そして報告について同時に質問をしました。彼は明日ジョーカーで私たちと話します。



-どのようにJava EE 8-コミュニティにとって大規模で待望のイベントであり、どの革新が最大の共鳴を引き起こすか？



-私は一般的に、以下のオラクルの公式インフォグラフィックに同意します。







今日、REST、HTTP / 2、およびJSONに関連するすべてのものに対する大きな需要があり、EEはここの傾向に従います。 JSON-Bの必要性は明らかであり、誰もがそれについて非常に満足していると思います。 これにより、開発全体が大幅に促進されます。 非同期性/反応性に加えて、もちろんセキュリティにも多くの注意が払われています。 すべての変更を考慮すると記事全体が描かれますが、もちろん、Java EE 8のリリースは非常に期待されていました。 今では、最新のエンタープライズ開発のためのインフラストラクチャ全体を提供する、まったく新しいプラットフォームです。



-そして、あなたはあなた自身の実際の仕事に関連して何を感じますか？ G8には、T-Systemsプロジェクトで明らかに役立つ何かがありますか？ そして、仕事の変化をどのくらい早く感じますか？



-いくつかの新しいプロジェクトでは、MicroProfile + JSON-Bスタック、そしておそらくMVCを使用する必要があります。 私たちには多くの非同期性とイベントがあり、ここでITS 8は私たちの生活を大幅に簡素化します。



そして、時間について-T-Systemsのような大きなプレーヤーでは、そのような変化はすぐには感じられません。 私たちには数年前の多くのプロジェクトがあり、最新のプラットフォームへの移行は必ずしも即座に行われるわけではありません。 多くの場合、これはかなり長いプロセスであり、多くの事前チェックに関連付けられ、サンドボックスで機能します。 何よりも安定性と安全性。



それにもかかわらず、私たちは常に最新のリリースを適用するよう努めていますが、「ファッショナブルだから」と頭を痛めません。



-コミュニティはEEからEclipseへの移行をどのように評価していますか？ 主に感謝の言葉が表示されますが、「Oracleはバラストを取り除く」などの懐疑論もあります。コミュニティとあなたはどう思いますか？



-もちろん、これは宇宙規模のイベントです。 想像してみてください-プラットフォームは25年間、たった1つの企業によって制御されていましたが、この巨大な部分はそこから脱却し、独立したナビゲーションに入ります。 ITSは非常に広範であり、コミュニティは非常に大きいため、何が起こったのかは自然なことです。 しかし、私はそれを「バラストを取り除く」とは呼びません。 ここでは、パブリックドメインになったことを嬉しく思うだけです。



私の謙虚な意見では、これは遅かれ早かれ起こることでした。 しかし、私はこれがすぐに起こるとは思っていませんでした、そして、現在、私はこれらすべてを興味を持って見ています。



「昨年、コミュニティは、Oracleの管理下でEEの開発が遅いと苦情を言いました。 しかし、Oracleウイングがなければ、それは加速せず、さらに減速し、すべてを返すようにOracleに要求することが判明しますか？ :)



「間違いなく。」 このイベントは、業界のニーズに合わせたこのプラットフォームのより迅速な開発を促進するものと確信しています。 さらに、メインベンダー（サーバー開発者）がこれに関心を持っているため、EEはさらに汎用性が高く、ポータブルになります。 これで、彼らが座ってこれを標準化する方法に同意するのが簡単になります。 良い例がMicroProfileです。 数社のサーバーベンダーが座って、このサブネットEEをどのように見たいかについて合意し、一般の人々と相談して実装しました。 すぐにすべての欠点が表面化し、委員会はすぐに反応しました。 私にとっては素晴らしいことです！



-誰もがMicroProfileを正しく知っているわけではありません。 T-Systemsで役立つと確信しているので、不足しているプロジェクトについて一般的に説明できますか？ そして、MicroProfileをEE4Jに移行したいと考えている今、MicroProfileの見通しは何ですか？



-一言で言えば、その外観はマイクロサービスの巨大な人気によるものです。 これは絶対にコミュニティのイニシアチブであることは注目に値します。 そのため、1つのRESTエンドポイントを上げるために、永続性とJSFなどの両方のEEインフラストラクチャ全体を上げる必要がある場合がありました。 理解してください、これはすべきではありません。 そして、ここに集められ決定されたEEサーバーのベンダーがいくつかあります。過剰なものはすべて捨てて、JAX-RS、CDI、JSON-Pのみを残しましょう。 これは通常、マイクロサービスを実行するのに十分です（ただし、これはまだ議論の対象です）。 それでMicroProfileができました！



同時に、サーバーディストリビューション自体が非常にコンパクトになり、多くの場合1つの実行可能jarにパックされます。 このような脂肪の瓶のサイズはめったに40メガバイトを超えません。 私が共同リーダーであるブルガリアのJUGでは、MicroProfileの開発に積極的に関与しており、積極的なコミッターがいます。 さらに、このトピックに関する最初のハンズオンラボを作成しました。ワークショップでは、複数のマイクロサービスで構成されるWebアプリケーションを作成し、各マイクロサービスはベンダーからサーバーに移動します。 そして、これらすべてが単一の標準であることを考えると、すべてが素晴らしく一緒に機能します！ とても楽しい！



ちなみに、EE4Jという名前は好きではありませんが、このイニシアチブは間違いないでしょう。



-Oracleが最初にJava EEからMVCプロジェクトを見つけ出し、コミュニティがそれを別のタスクとして選択し、今ではEE4Jにマージするという話がありました。 オラクルは「誰も必要ない」という理由で拒否しましたが、あなたの気持ちによると、それはどれほど関連性があり、関連性がありますか？ これに対する需要は、コミュニティ、具体的にはあなたの作品に現れていますか？



-私はこれを言うだろう：MVCは良いです。 JSFが困難で「標準的」すぎるタスクが多数あるため、JSFに代わるものを持っていることは非常に良いことです。 さらに、このモデルはSpringで実証されています。 これまでのところ、世論調査と一般的な騒音から判断すると、人々はまだ彼女に彼女を本当に受け入れていません。 しかし、上記で述べたように、T-Systemsでは、プロジェクトの1つにMVCを適用することを考えています。



-Java EE Guardiansコミュニティは常にEEに関連するすべてのことについて大声で話しますが、側からは明らかではありません。それは本当に志を同じくする人々の強力なコミュニティですか、それとも本当に「Reza Rahmanとそれ以上の人々」ですか。



-Rezaは間違いなくEEの柱の1つです。 つい最近、私は会議で彼の共同スピーカーを務め、私たちは彼女の将来について話していました。 そして、ガーディアンは数人の人々からはほど遠い。 EEサーバーの作成者であるJames Goslingから始まり、多くのJCPエキスパートであり、最後にEEの単純な「ユーザー」で終わる参加者のリストをご覧ください。 実際、ガーディアンズは、EEの停滞に最初に注意を払い、その深刻さに関する神話を「払拭」する動きを開始し、業界の新しいニーズを満たすプラットフォームの進化に貢献しました。



-神話の質問へ。 現在、「一般的に誰がこのEEをSpringの最盛期に必要とするかもしれない」という気分がありますが、それは「ファッショナブルではない」ことが判明しますが、EEで作業している人の観点からはどうですか？



-実際、EEで実行できることはすべて、Springで実行できます。 さらに、Springにはさらに多くの「砂糖」があるため、プロトタイピングや一部の迅速な開発のために、場合によってはそれが望ましいこともあります。 しかし、あなたはこの決定の「人質」になります。 他のものへの移行は非常に困難になります。 EEには、すべてが機能するサーバー上の代替手段が常にあります。 さらに、一部のEEベンダーは、絶対に匹敵する砂糖のセットを提供しています。



しかし、EEが「流行遅れ」であれば、それほど一般的ではありません。 私はいつも言っていました：EEは、プラットフォームの内側と側面の両方でかつて発明された最高のものです。 これが企業の本質であり、標準に値するものです。



-ジョーカーの過去に、Java EE 7からJBatchについて話しましたが、自分で使用していますか？



-アプローチを2回使用しました。これにより、アプローチが可能な限り標準であるため、余分な労力を大幅に節約できました。



-なぜ尋ねられたのか：JBatchは多くの労力を節約しているように見えますが、その参照はほとんどありません。 なぜこれが起こっているのですか？ 慣性の人々は、自転車が不要になったとしても自転車を作りますか？



-はい、私自身はJBatchを「忘れられたAPI」と呼んでいます。 しかし、私は上記のように人々が自転車を発明する方法を見続けています。 多くの人は、タスクが非常に単純であると考えているので、なぜ考えるのでしょうか？ 数サイクル、本番で書きました。 そして、あなたはあなた自身が続くものを知っています。 そして、並列コードを書かなければならないとき、すべてができるだけ悲しくなります。 しかし、タスクがもう少し複雑に思える場合は、もちろん、誇大広告から何かを取り出すのが慣習であり、これはしばしば不必要な困難につながります。 JBatchの欠陥に関して、主なものはその不明瞭さです。 これが理想的なツールではないことは明らかですが、問題を適切に定式化すると、時間を大幅に節約できます。 さらに、このようなAPIの可用性に関する知識は、特定のアプリケーションのアーキテクチャ設計に役立ちます。



-最後に、EEトピックから少し離れましょう。次のJokerでは、「JavaとGPU」 に関するレポートがあります。これは、JBatchと同様、めったに話されません。 これも個人的な経験に基づく非定型のテーマですか？



-私はあらゆる種類の異国情緒について話すのが好きだということに気づきましたか？ 私は数年前からGPUを好んでいましたが、はい、個人的な経験に基づいて教えますが、例はより一般的です。 私の以前の仕事では、アプリケーションの直接的な経験がありました。そこでは、多くのヒートマップをすばやくカウントする必要がありました。 そして今、T-Systemsのイノベーショングループでは、クラウドなどのニーズにGPUを使用する可能性を検討しています。 ビデオカードでのコンピューティングの性質上、どこでもアプリケーションの範囲が制限されるため、これをまとめて適用する必要はないと思います。



-さて、これは皆のためではありません。 しかし、今ではJavaでGPUを使用するのに役立つ人たちは今ではしばしばそうではないという感じがありますか？



-私の意見では、GPUは暗号通貨の急速な成長とブロックチェーンに関連するすべてを背景に特に評価されています。 Javaは、金融および銀行業で非常によく代表されています。 実際、それはそこで支配しています。 しかし、この分野には、大規模並列クラスに適合する他の多くのタスクがあり、GPUに最適です。 さらに、プログラマーが原則としてGPUと通信できるようになることは興味深く、有用であると確信しています。 最近、私の謙虚な意見では、開発者とアーキテクトは、特定のタスクがどれだけ並列化されているかを判断し、これに基づいて最適なデバイスに実装する能力を必要としています。 個人的には、タスクが適切であることがわかったら、もちろんGPUを適用しようとします。 さらに、このリソースはますますアクセスしやすくなりました。



-ありがとう、ジョーカーであなたとT-Systemsの両方を待っています。