Java EE5.XとEJB3.Xは両方とも簡潔さと軽量開発の実践を追求したものだ。それでもまだPOJOソリューションのほうがシンプルで簡潔なコードであることは事実なのか？Adam Bien氏はそれに同意していない（source）。
実はEJB3.0を簡潔にするのは困難なのだ。（提案があればいつでも受け入れている。）
面白いことは・・・EJB 3 Session BeansなしのJava EE 5ウェブアプリケーションはもっと複雑なのだ。
彼はEJB 3を用いたもの、用いてないものの二つのコードの断片を使って実演している。結果は下記のとおりである。
Matt Coreyは下記のように付け加えている。コードが簡潔なだけでなくきれいになる。そのリソースはコンテナによって注入され管理されている。しかし単体のSession Beanの導入を用いると管理性とモニタリングを大幅に増やすことができる。Glassfishのコールフローのようなツールを用いると呼び出しのスタッ ク全体のパフォーマンスをモニターすることができる。すごいのはXML設定がオプショナルということだ。EJB3.1内ではローカルインターフェースでさえオプショナルとなる。
EJB3.1内ではもはやウェブアプリケーションから離してEJBをパッケージする必要がないということを考えると、これはとても面白くなってくる。 JSRにはこう記されている”簡潔化されたパッケージングのオプションを含めてサーブレットコンテナの中のEJBの直接使用をサポートする。”
Jason Carreiraがそれに対立する意見を述べている。
要はEJB3とEJB2.1は同じくらい優れているが、SpringはEJB 3よりも断然優れているということです。EJB3の依存性注入はフルパワーに比べるとかなり弱いのでSpringはスタックをまとめるためのワイヤーを提供するのです。
それに加えて、Springを持ってきていつも一貫性のあるインプリメンテーションができるのに、私はなぜEJB3スペックを実装する異なるアプリケーションサーバに頼りたいのでしょう。私が一つの特定のインプリメンテーションを使うことにすれば、それをどんなアプリケーションサーバやサーブレットコンテナにでも使用することができるのです。そしてスペックが進化して変更されても、自分がそうしたくなければコードをアップグレードや変更する必要がないのです。最 新のアプリケーションサーバは五年後でもEJB 3アプリケーションを作動させるでしょうか。しているかもしれないし、していないかもしれません。
SpringとEJB3の比較はよくあるもの（source）だ。たくさんの人たちがEJB 1.Xと2.Xの複雑さから離れてSpringに移行した。そして今EJB 3、またはGroovyとGrails、RubyとRailsのような大幅な移行がどう比較されるか考慮され始めたのである。
Java Enterprise EditionはEJB3を用いるのと用いない場合どちらがシンプルだろうか。もしあなたが以前のEnterprise JavaBeansを使ったことがあれば、よりシンプルになったJava EE 5でEJBをもう一度使いたいと思うだろうか。