DIContainerはコモディティ化する

SpringやSeasar2など、現在のDIContainerは、独自の機能を追及し、機能の豊富さを競っているようなところがありますが、この動きはもう直ぐ終わりを迎え、DIContainer自体は、コモディティ化するでしょう。
例えば、DIやライフサイクルのアノテーションの@Resource, @PostConstruct, @PreDestroyなどは、common annotationとして定義され、SpringやSeasar2では、既に利用可能になっていて、独自のアノテーションよりもこれらのアノテーションを使うほうが(Seasar2の場合は)推奨されています。
Seasar2では、既に、EJB3.0にも対応していますし、SpringもPitchfork ProjectでEJB3に対応しているので、Spring 3.xでは、コアでEJB3.1に対応してくるでしょう。

EJB3.0は、インターフェースが必須だったり、jarファイルにしないとデプロイできなかったり、まだまだめんどうなところが残っていましたが、EJB3.1では、これらの問題も解決されました。

今後のDIContainerは、EJB3.1に集約されてくるんじゃないかなぁ。各コンテナ独自の機能は互換性のため残るでしょうけど、標準の機能のほうが推奨されるはず。

Slim3は、EJB3.1のサブ実装にする予定です。サブ実装とは、EJB3.1をフルには実装しないという意味です。@Singletonなど、HOT deployと相性の悪い機能は、実装しない予定なので、サブ実装の位置づけにしています。
Slim Struts(SAStruts), Slim JDBC(S2JDBC)は、JNDIのInitialContextを通じて、EJBContainerとやり取りをします。Slim Containerを使わずに、アプリケーションサーバが提供するEJBContainerと連動することも可能です。
Slim Containerのメリットは、HOT deployができることです。HOT deployがいらないプロジェクトは、標準のEJBContainerをそのまま利用できます。
Slim Struts, Slim JDBCが自動生成するコードは、Slim Containerでも標準のEJBContainerでも、どちらでも動くようになるでしょう。

DIContainerがコモディティ化した後は、フルスタックでいかに価値のあるものを提供できるかが勝負になってくると思っています。