Javaの面白さの1つに,情報が拡散しているということがある。

 たとえば──ここで比較されるのはお互いに不本意かもしれないが──マイクロソフト社の技術であればMSDN( 注:この記事では日本語サイトが存在する場合はそちらのURLを紹介している)に集約されていると考えてよい(最近ではGotDotNet)のようなコミュニティ指向のサイトも存在するが)。したがって,定期的にMSDNをウォッチしていればマイクロソフトの技術動向についてはだいたい押さえることが可能だ。これはシステムを構築する側の我々にとっては有難い。

 企業システムは1度構築してしまうと,プレゼンテーション層(Webのユーザー・インタフェースなど)を除けば数年から10年近くは大幅な変更はできなくなる可能性が高い。それを考えると,やはり数年後にどのようなテクノロジが主流になるのかを見届ける必要がある。

 もちろん表裏の関係としてヴェイパーウエア(実際には存在しない製品)に惑わされる危険性や,大して意味があるわけではないマーケティング的な(実質的なテクノロジを伴わない)バズワードに惑わされる可能性もある。だからと言って,テクノロジ・トレンドを無視してシステムの寿命よりはるかに短命にフェードアウトしてしまうテクノロジを採用してしまえば後々苦労することになる。

 たとえばその時点でシステムの基盤としているテクノロジがなくなっていれば,本来単純な修正で済むはずのものがシステムの再構築同然の作業になってしまう可能性があるのは自明だ。もちろん通常はベンダーもフェードアウト後しばらくはサポートするわけだが,それにしても既にフェードアウトしたテクノロジ上に新たなサブシステムを追加するといった作業はどうしてもプロジェクト遂行のモチベーションが低くなりがちになるのは避けられない。

 これがメインフレーム時代であれば,いずれにしろメインフレーマから情報を受けるしか他に手段がないから,それでも良かったのかも知れない。しかしオープンシステムはベンダー同志も厳しい競争にさらされているわけだから,次から次へと新たな手を打ってくるのは,それは当然のことなのだ。そのため,結局,自分達の手で情報収集することは欠かすことができないことなのだ。

 さてJ2EEでシステムを構築すると決めたとしよう。では,どこから情報を収集すればよいのだろうか?

 もちろんマイクロソフトがそうであるように,Javaに関連した製品を出荷しているベンダーサイトからの情報発信はある。しかもそれらはそれぞれ質が高い情報を提供している。例を挙げればSun(「本家」java.sun.comJDC,昨年できたjava.netがある)やIBMのdeveloperWorks,BEAのdev2devなどだ。ここで挙げたサイトはベンダーが提供する情報とは言え,必ずしもそのベンダーの特定製品に偏ることなく,広くシステム構築やプロジェクトの進め方,あるいはプログラムの実装といった各種ノウハウや技術動向についての記事を提供していることが特徴だ(それもJavaがオープンプラットフォーム――いささか微妙な表現ではあるが――だからこそ可能なのだろう)。特に,IBMのdeveloperWorksは翻訳にも熱心だし,一貫して質が高い情報を提供しているため好感度が高い。

 しかし情報の質は高いにも関わらず,これらのサイトがマイクロソフトのMSDNにかなわない点が1つある。それは,これらのベンダー情報サイトをウォッチしているだけではJavaの最新動向が掴めないということだ。

 たとえば,つい3週間ほど前EJB3.0の概要が明らかになったが(参照記事),この動きはこれらベンダーのサイトをウォッチしているだけでは,ほとんど予測できなかったのではないだろうか。

 そういう意味では,この発表の場がJavaOne――誰もがJavaの正式なカンファレンスと認めるイベント――ではなく,TheServerSide Symposiumという外部の1企業が主宰するイベントで次期仕様が明かされるということも異例に感じられるかも知れない。これがマイクロソフト社の技術であれば,次期Windowsや.NET Frameworkの仕様のように大きな影響を持つ発表がPDCやTechEDのような正規イベント以外で行われ,それがニュースとなるということは考えにくい。

 翻ってみれば,以前Javaをオープンソースにするかどうかが話題になったことがあるが(参照記事)。しかしJavaそのものがオープンソースかどうかは別としても,これらの動向を見ている限り,Javaの仕様に関しては十分にオープン性を保持していると言えるだろう。

 そこで「では,どこでEJB3.0の仕様の論議が行われていたのか? どこでそれを知ることができるのか?」という疑問を持たれるかも知れない。

 この疑問に対するおそらく最も公的な解答はJava Community Process(JCP)のWebサイトである。

 特にJava Specification Requests(JSR)と呼ばれる一群の文書(レビュー中,初期ドラフトレビュー,公開レビュー,正式承認後のメンテナンス・レビューに分かれている)をウォッチしていればある程度までは予測が可能かも知れない。たとえばEJB3.0であれば,J2SE 1.5で導入されるメタデータを利用することや,環境への依存性とJNDIアクセスをカプセル化する便利なユーティリティクラスや/とファクトリパターンの提供といった項目が挙げられている。

 とは言え,JSRはベースとなる議論ではなくその結果としてのリクエストなので,なぜそのようなリクエストが生まれたかといった背景までがわかりやすく提示されているわけではない。

 そこで,これらの論議が行われている場を1つあげるとすれば,それこそがTheServerSide Symposiumを主宰したTheServerSide.comだ。運営しているのはMiddleware Company というトレーニングとコンサルティングの専門企業で,.同様にTheServerSide.NETという.NETのコミュニティサイトも運営している(筆者の見た感じだとこちらはGotDotNetという強力なライバルがいるためか,TheServerSide.comほどには成功していないように見える)。

 TheServerSide.comのメインコンテンツはコミュニティベースのBlog(スラッシュドットなどと同様)で,トップレベルに投稿時刻とコメント数付きでヘッドラインの列挙があり,それらをクリックすると,実際の記事とそれに対する読者のコメントが読めるようになっている。ニュースやコメントは登録すれば誰でも投稿できるため(その他,署名記事などもある),そこで種々の論議が行われるのが特徴だ。各記事のコメントの数を見ればある程度まではどのような動向に関心が集まっているのかを知ることもできるだろう。たとえば5月23日現在のホットスレッドのコーナーを見ると「EJB3.0 and JDO2.0: View from both sides」という記事が253コメントで特にホットだということがわかる。ちなみに,この記事の執筆時点でのTheServerSideへの登録者数は360,777人だ。なお,読むだけなら登録の必要はないため実際の読者数はもっと多いかも知れない。この人数が,EJB3.0の発表にJavaOneを待たなかった(待つ必要がなかった)という推測もできるだろう。

 なお,読者の参考までにTheServerSide.comから軽量コンテナ(DIコンテナ:注:EJBではなくPOJO=通常のJavaオブジェクトを利用するコンテナ,DIに関する解説はこちらを参照)関連のニュースのリンクを示す。これらのページ群から,EJB3.0のうち依存性注入(DI:Dependency Injection)に関してどのような動きがあったかをおさらいすることができるだろう。

  • PicoContainer 1.0 beta 1 has been
     コメント欄でSpring Frameworkとの依存性注入の方法論の違いによるちょっとしたフレーム(論争)が起きている。なお,PicoContainerは,最初コンストラクタベースの依存性注入をサポートするコンテナとして開発された。この場合,コンテナによって生成されるPOJO(ビジネスロジックを実装したオブジェクト)は,依存するインタフェースをコンストラクタで受け取るように記述する。

  • Introducing the Spring Framework
     Rod Johnsonによる署名記事を受けたもの。Spring Frameworkは最初,依存性注入にセッタメソッドを利用するように開発された。

  • Tech Talk with Bill Burke on JBoss 4 and the AOP Framework
    JBossグループのチーフアーキテクトのBill Burkeのインタービューを受けたもの。

  • Martin Fowler renames IoC: Dependency Injection
     Martin FowlerがIoCという呼び名からデペンデンシ・インジェクション(依存性注入)という呼び名への変更を提案したことを受けたもの。Rod Johnson(Spring Framework)やAslak Hellesoy(PicoContainer)によるIoCコンテナからの名称変更への同意がある。なお,この時点では両者はコンストラクタとセッタのいずれでも依存性注入可能としている。

  • EJB 3.0―What’s wrong with @Inject?
    EJB3.0での依存性注入アノテーションの@Injectという名称に対してAspectJ(JavaをAOP対応させるためのプロジェクト)のAdrian Colyerの見解を受けたニュース。JBossのBill Burkeのコメントで,コンストラクタベースの依存性注入ではビーンのプーリングに対応できないためEJB用にはならないという指摘が興味深い。

     本稿ではもっぱら依存性注入(DI)に関するページを取り上げたが,同様にCMPからJDOやO-Rマッピングなどについての論議もあるので,それらについても一読をお勧めする。






    筆者紹介 arton


    謎のITエンジニア。RTOS上でのデータベースエンジンを皮切りにミドルウエアやフレームワークとそれを利用するアプリケーションの開発を行い現在に至る。専門分野がある業界に特化しているために逆にメインフレームクラスから携帯端末まで,その時の需要に応じてダウンサイジングしたりアップサイジングしたりしながらオブジェクトを連携させていくという変化に富んだ開発者人生を歩んでいる。最近はもっぱらJ2EEが主戦場。著書に『Rubyを256倍使うための本 邪道編』『Visual C# .NETによるWebプログラミング入門』共著に『J2EEプログラミング講座』(いずれもアスキー刊)などがある。