DIコンテナ2.0

Java T2Framework


ひがさんのDIコンテナはEJB3.1でコモディティ化するという意見には賛同しかねるなあ。
自分はあんまりDIコンテナがEJB3を中心にコモディティ化するとは思わない。
何故なら、EJB3を初めとするJavaEEの仕様がそこまで受け入れられてるわけじゃないからです。
もう少し言えばJSF+EJB+JPAの組み合わせが残念ながら受け入れられてない。
海外では標準として受け入れられているかもしれないけど、標準なら標準のまま使うのが
王道でしょう。それか全体を統一してしまうSeamかなあ。


今後JavaEE5のAPサーバが出て、日本でも標準としては間違いなく今よりは
使われるようにはなると思います。その意味でJSF+EJB3+JPAは覚えておいて損は無いです。
しかし、標準からずれてわざわざOSSを使うのであれば、それなりに標準よりメリットが
なければ利用者にとって意味がありません。OSS開発する方としてもEJB3よりは良いものを
追求する必要が勿論あります。
Slim3もHotDeployできるEJBとして実装するよりは、EJB3.1のサブセットよりかは
HotDeploy+独自性を追及するほうが面白いんじゃないかと思っています。


世の中的にはJavaEE6の時代が次のターゲットになりますが、
JavaEE6でプロファイルが導入されたときにJSF+EJB+JPAがどれくらい受け入れられたかの
真実の姿がわかるでしょう。自分の想定では、今同様JSF+EJB+JPAはあまり受け入れられず、
一番シンプルなWebプロファイル（Servlet3+JSP+JDBC4）が最も受け入れられ
長く使い続けられるとよんでいます。


翻ってみて、T2のサブプロジェクトのLucyは独自路線をひた走るDIコンテナです。
Lucyはアノテーションとかも全部自前。一部だけ標準アノテーションとかを使うよりは、
そっちのほうが良いんじゃないかと思っているので。
今のところMLでわいわいがやがやで作りこんでて、まわりにも小さく小さく！！と
言われ続けていて非常に良い感じです。どんどんうるさく言ってくださいｗ


最近じゃ、おいらの提案（DependencyLookupをなるべくさせない仕組み）も
見事に却下されそう（ｗ）で良い感じです。ほんと嫌味じゃないよ。
いろいろな目線が入るのはとってもよいことなので。


DIコンテナって実はもっともっと可能性を秘めた分野なんじゃないかというのが
正直な自分の感想。やれることはいっぱいあるのですが、その中から厳選して機能追加したいですね。


ポイントは、以下の言葉を考え抜くことじゃないかと。


DIコンテナ＝Dependency Injectionコンテナ
オブジェクトの生成と管理を司るフレームワーク


この2つの大元の意味を考え抜けば、またひとつ違ったアイデアが
出てくるんじゃないかと思ってます。
特に

  • Depdencyって何だ？
  • Injectionって何だ？
  • オブジェクトの管理って何だ？


この3つがテーマです。まーだまだ考え足りない。


結論的には、標準より何よりも、シンプルで使いやすい・拡張しやすい、
そういうDIコンテナは今でも求められていると自分は信じて貪欲に追求してみたいと思います。


P.S.
勿論T2が開発の主体です。が、しかしサイドプロジェクトでは
DIコンテナってどんなんがいいんだろう？っていろいろ議論して開発しています＾＾