• JUG を作ろう!!

二年ほど前から Sun 社内、特に SDN チームと議論してきたことがあります。

「なぜ、日本には JUG (Java User Group)がないのか?」

原因を考えればいくつかのものがあげられます(政治的に微妙な理由も多いのであえてここでは書きませんが)。ただ、大事なのは原因を探求することではなく、ないなら作るべきか否かです。

IT産業が発達している世界中のほとんどの国や地域には JUG があります。
http://community.java.net/jugs/listing.csp
ブラジルの JUG は強力で、政治的な影響力すらあって、かの国で Java EE システムを普及させる原動力になっています。イタリアのJUGも活発なので有名ですし、韓国では近年、15ほどあったグループを統合して統一された JUG が誕生したそうです。今回の JavaOne では、その会長の Soo-Yeol Yang さんとお話させていただいたが、彼は韓国大統領と ITについて語り合ったこともあるそうです。その国での影響力の大きさを感じさせられる。先進国だけではなく、タイ、フィリピン、ハンガリー、スペイン、ベトナムにも JUG があります。

日本だけ JUG がないのは、本当に不思議な現象なのです。JUG はあくまでユーザ(開発者)の自発的団体であるべきです。Sun や他の企業が強引につくるものでもありません。US では、一部 JUG から Sun への強いプレッシャーがかかったこともありますが、それはある意味健全なことです。JUG はユーザ(開発者)を代表するものであって特定の企業の圧力団体であってはいけないからです。ユーザ/開発者が JUG を作りたいと思えば、できるものですし、必要ないと思えば誕生しません。ただ、もし日本に横断的な JUG ができるのであれば、それは、Sun として SDC として何らかの、無償のサポートをするべきだとは思っています。

現在、日本に JUG はありませんが、JUG に近いタイプのJava関係のグループはいくつもあります。それらが緩やかに連合する形で横断的な組織ができるのがとても自然かと思います。そして、この日本 JUG が受け皿になって、Java 開発者/ユーザが知識の共有を行い、互いに刺激しあえるのが理想です。 Java 技術が世の中に広がり、Java ME 分野で再びブレークの予感が出てきています。Java EE 5 もエンタープライズシステムでの Java の躍進を加速させそうです。日本国内でも、何らかの統一団体が欲しいという声もたびたび聞きます。今、国内で JUG を作るいいタイミングなのかもしれません。 JUG はあくまで自発的な団体ではありますが、その自発的な動きが起こるために何らかの行動をしてもいい時期かもしれません。

もし、日本の JUG 誕生に関して、ご意見があれば、ぜひこの Entry にコメントください。会長になって、小泉首相と語り合いたい、というご希望の方もどうぞ(笑)

無料で iPod Shuffle をゲットしましょう!!

SDC の個人会員(登録無料)に申し込んで(新規登録のみ)、iPod Shuffle を GET しませんか?

先月から SDC で行っている新規登録キャンペーンは好評です。幸い、少し余分に予算もつきましたので、6月も新たにキャンペーンを行います。6月末までに登録された方の中から抽選で5名の方に iPod Shuffle をプレゼントします。 まだ、SDCの会員でない方はぜひお申し込みください。特に新入社員が身の回りにいらっしゃる方、その部署で一台狙ういいチャンスです。ご遠慮なくお声がけしてください。

ただし、あたった iPod Shuffle は先輩写真がもいただくべきなのか、新入社員の方がもらうべきかについては私ども、コメントを差し控えます(笑)。とりあえず、iPod Shuffle は登録された方にお送りいたします。

ただ、J2EE アプリケーションサーバーが普及していくなかで次第に明らかになってきたのは EJB とくに CMP が思ったほど活用されないということです。CMP に関しては当初のパフォーマンスの悪さや使い勝手の悪さが尾をひいて、実力よりはるかに低く評価されている感はぬぐえないのですが、ともあれ、利用される割合が少なかったのは J2EE を普及させる側からすると誤算には違いありませんでした。

多くの試行錯誤と改善の努力の末、今、J2EE (Java EE)に画期的な API が導入されました。それが New Java Persistence API (JSR-220, 以下 JPA) です。JPA は何より政治的に大きな意義をもつ API と私は考えています。隆盛なO-Rマッパを EJB の中に取り込んだこと、そして Java EE の一部として、つまり正当な標準技術としてお墨付きを与えたこと、そして何より大きいのは、EJB と切り離して、単独で存在することを許容したということ。
特に、最後の点、JPA が、単独で Java SE と組み合わせて使用できるようになることは何より大きい。これによって、Java エンタープライズシステムのアーキテクチャーのありようは大きく変動を迎えると私は考えています。

正統な技術としてデビューしたものの存在感が今ひとつだったEJBはこれで完全にプラットフォームの「内側」の技術になるでしょう。EJB そのものが消えるのでは、と考えるのは一面的過ぎます。当初の期待ほどではないにせよ、やはり EJB は使用されており、特にツールやミドルウェアが自動生成するコンポーネントとして EJB は優れています。BPEL エディタが吐き出すコンポーネントの多くは実は、MDB のような EJB であることが多いでしょう。自動生成される Web サービスの実態も、Statless Session Bean ということになるケースが多いでしょう。ただ、ポイントは、それはもはや一般の開発者の視点からは多い隠されてしまうということです。

言葉を変えていえば、EJB は、今後 API ではなく、SPI 的な存在に転化するだろう、ということです。そして、身軽になった Java EE の主な API はより上の層、Composite Applications に比重を移すでしょう。EJB ではなく、何らかのコンテナは引き続き必要です。しかしそれは EJB2.1 以前の重量コンテナではなく、別の何かです。これらの動きは JPA の導入を契機として起こってくるのです。

Java EE (J2EE)は、非常にしたたかかな存在です。中心に君臨しながら、周縁のテクノロジーをたくみに中にとりいれ、生き残ってきたブランドです。コンテナ/コンポーネント思考、CORBA、MOM、Web サービス、DI、AOP 周辺の技術をたくみに取り入れ、先進性、存在意義を確保してきました。ただ、ブランドが生き残ることは開発者にとって、ユーザにとって決して悪いことではありません。長らく続くブランドが、信頼性を醸成していることはテクノロジーの発展、普及には非常に重要な要素だからです。
中心としての Java EE ブランド、そしてそのブランドの下側にあるテクノロジーとの二重構造、これを確定させたのが、Java EE 5、そしてその中で導入された New Java Persistence API だと思うのです。開発者にとって、好ましいテクノロジーが、安定した Java EE ブランドの元で花開く。悪いストーリーではありません。今だからこそブランドの強みに感謝し、そしてその信頼性を最大限利用すべき時なのではないでしょうか。

最近、Java EE (旧 J2EE)ブランドについて考えることがあったので、少し記してみたいと思います。

Java EE ブランドに関して、Sun が最も強固だったことは、誕生以来、長らくの間、J2EE のサブセットを認めてこなかったことと言ってよいでしょう。各種ベンダからの要望 - 一番多かった例は、Web コンテナ(つまり、JSP と Servlet コンテナだけのセット)だけの製品に J2EE ブランドをかぶせて欲しいという要望でしたが、それを Sun は拒み続けてきました。
この圧力は相当強いものだったにもかかわらず、Sun が決して認めなかった理由は二つあると私は考えています。

一つは、プラットフォーム・ブランドの維持です。Microsoft のテクノロジーの場合、テクノロジーは即ちマイクロソフト社の製品であるので分化は起こりえませんが、Java ソフトウェアは誰もが自由に実装することが許されています。J2EE という仕様があっても、それに忠実に従った製品もあれば、サブセット版もあり、仕様に一部反する亜流も存在します。それらすべての存在が許される混沌とした世界だからこそ、互換性がきちんと保障された製品には明確なお墨付きによって差別化することは重要です。

「それにしても、Web コンタナ限定のサブセット版くらいは存在を認めてもよかったのでは」という議論もあるかと思います。これは難しい問題ですが、プラットフォームやブランドはいたずらに分化すべきではない、のも事実です。Java ME の世界では、ハードウェアの特性からフラグメンテーションやプロファイリングを認めざるを得ませんが、エンタープライズの世界は、できればきれいな単一のプラットフォームが存在はより重要でしょう。"J2EE Web Edition " を認めれば、"J2EE XML Edition" やら "J2EE Web + DB Edition" といった、様々な Edition への要望が出てきて収集がつかなくなったことも容易に想像出来ます。"Web Edition"を認めないことで、ブランドが瓦解することの歯止めとしていたと言ってもよいかもしれません。

Sun のブランド関連チーム、リーガルのこの必死の防衛作業は、誕生まもなく、まだまだ、か弱かったJ2EE ブランドにとっては大きな意義のあったことだと思います。統一された正統ななブランドを確立することで、J2EE は「中心と周縁」の中心としての役割をきっちりと果たしたわけです。周縁は、様々な次世代のテクノロジー、アイデアが生まれる exciting な場ですが、中心がしっかりしているからこそ周縁も存在意義が与えられ、活性化するわけです。

二番目の理由は、最初の理由とも関連するのですが、Sun (及び主だった J2EE ベンダー)は EJB を守ろうとした、ということです。EJB はエンタープライズシステムの中核となるべく生まれてきたテクノロジーで、アイデアそのものはすばらしいものでした。今でこそ、DI の発想が普通になりつつありますが、DI のベースとなるコンテナ/コンポーネントのアイデアは EJB が Java の世界に導入したことは忘れてはなりません。

ともかく、J2EE を普及させるにあたって、EJB は戦略的に必須の要素でした。一方、当時主流だった Web アプリケーション開発は Web コンテナのみが利用され、EJB 層の実用度は低いとみられていました。。ただ、ビジネスロジックの層になんらかの中核コンテナが必要なことは明らかで、今日の Spring や Seasoar などの軽量コンテナの普及は図らずもそれを実証しているといえなくはないと思います。Java エンタープライズシステムの開発に「中核コンテナ」をもたらす意味でも EJB コンテナは必ず普及させなくてはいけなかったのです。(それが EJB でなくてもよかったという議論は成り立つかもしれませんが、軽量コンテナも注目されていなかった当時、ほかに代わるものはあり得なかったでしょう)

(To Be Continued)