Javaにケンカを売ってみるテスト
前回、サンとリクルートのマッシュアップアワードのサンプルをアップしましたが、
Developer's Lounge 4thでリクルートの八木さんとお話させていただく機会があり、
Curlで作ってもいいもんですかね、聞いたところ、ＯＫとのこと。
であればいっそのことJavaアプレットにケンカを売ってみようということになり、
（サンの藤井さんにたきつけられたところもありますが）
この項では、マッシュアップを作成するにあたって、どのようなポイントに気をつければ
いいかを考えてみました。
Curlアプレットはソースコードとして配布され、実行される際はクライアントでコンパイルされます。
そのため、非常に高速に処理が実行できるわけです。
また、CurlはCPUを100%まで有効活用できる仕様であることも、高速処理に大きく寄与しています。
JITやHotSpotの誕生で、「Javaは遅い」というのは前時代的な先入観といわれるようになってきましたが、
それでも、「Javaは早いか？」と聞かれると首を傾げてしまうところでしょう。
最近の傾向としてリッチクライアントアプリケーションに求められる処理の質的量的な増加がありますが、
Curlであれば、複雑な処理でもユーザーにストレスをかけずに行うことができます。
また、この「クライアントコンパイル」という仕組みは、別の面でも大きなメリットを持っており、
それはCurl上では「ダイナミックロード」と呼ばれる機構で実現されています。
たとえば、複数のパッケージを利用するアプレットが、実行の最初の段階ですべてをインポートするのではなく、
そのパッケージが必要なタイミングでにダイナミックにインポートできるというものです。
これにより、ただでさえ「ソースコード」という軽い容量で配信されるCurlアプレットが、
ロード時間が分散されることでさらにユーザーのストレスを軽減できるだけでなく、
WEBサービスなど、実際にアクセスして実行するまで内容が分からないモジュールなどにも、
ＷＳＤＬなどの定義ファイルからクライアントでソースを自動的に生成し、
ダイナミックロードすることで、アプリケーションへ「動的に機能を追加」することが出来るわけです。
（このあたりは＠ITリッチクライアント カンファレンス でも触れています）
リソースへのアクセスにもCurlとJavaには大きな相違があります。
Javaは基本的にアプレットの配信サーバーにのみアクセスを許し、
クライアントマシンにはアクセスできない仕組みになっています。
Curlはサーバー、クライアントどちらにもフルアクセスが可能です。
（FTP、SMTPなどのプロトコルは利用できない）
そのため世界各地で展開されるWEBサービスなどにも自由にアクセスでき、
個人が作成したエクセルファイルなども簡単にアプレット上で利用できるのです。
ここまで出上げたCurlの優位性をまとめると以下の３つになります。
①クライアントでのコンパイル
②CPUの賢い利用
③リソースへの自由なアクセス
もちろんここで上げたポイントのいくつかは、
逆の視点で見れば「Javaはセキュア」であるというメリットにつながるので、
一概にCurlの優位性とも言い切れません。
つまり、「堅牢な環境」と「自由な操作」のトレードオフがそこにはあるわけで、
それでもおそらく、現在の潮流としてはユーザーに権利が移りつつあり、
より自由な操作が可能な言語をユーザーは求めていると感じています。
携帯電話のauで、容量に制限のあるJavaアプリケーションから、
より容量の大きなアプリが作成できるBREWに主導権が移っているのも、その一端でしょう。
ここまでアンチJavaの仮面をかぶってつらつらと書いてきましたが、
別にJavaが嫌いなわけではないんですよ。
サーバーサイドJavaとはCurlの連携事例もたくさんありますし。
あくまでJavaアプレットにケンカを売る「テスト」ということで、
Java技術者には温かい目で見守っていただけると助かります。
あと、これからは今回上げた優位性を意識したマッシュアップのを作っていこうとおもっていますが、
Curl陣営に加わってくれる奇特な方がいれば、大歓迎ですので、ご連絡お待ちしております。
