BlazeDSとAMFでWebとデスクトップのアプリケーションを構築する
現在のRIAアーキテクチャにおいて、クライアント/サーバーの通信は重要な位置を占めています。本稿では、James WardとShashank TiwariがアドビによるオープンソースのBlazeDSメッセージングサーバーの世界へ飛び込みます。
- Java,
作者 Werner Schuster, 翻訳者 長部 広太 投稿日 2007年9月10日 午後8時7分
JRubyの開発者メーリングリスト(source)で、Java5への移行に関する議論(source)が開始された。Java5がリリースされてからというもの、Javaの数々のプロジェクトで、この手の議論はよく起こる。OSGi又はSWTのような基本的な技術やライブラリはJava1.1又は1.2と互換性を保っている(source)が、Eclipseのように多くのJavaプロジェクトは、出来るだけ長くJava1.4と互換性を保ち続けることを選んだ。
Java5への移行に関して、スタンドアローンアプリケーションは必要としているJVMを同梱すれば特に問題にはならない。それに対してライブラリは問題がある。何故ならJava5への移行は、基本的にJava1.4を使用する事が前提のライブラリがJava5を使用するライブラリを使う事は出来ないし、Java5を必要としている新しいバージョンのライブラリも使う事が出来ない、ということを意味しているからである。
JRubyはスタンドアローンアプリケーションとライブラリの間に位置する。結局以下のコマンドを使えば、どんなRubyプログラムも実行させることが可能である。
jruby filename.rb
このために、それがJava5のライブラリを必要とする特有のJRubyのコードでない限りは、特定のJavaのバージョンを必要としているJRubyは問題ではない。アプリケーションの内側で組み込みRubyインタプリタとしてJRubyが使われた場合、JRubyはライブラリとして使われていると言える。
このために、JRubyを使用するのに必要とされるJavaのバージョンを上げてしまうと、もしそのアプリケーションがJava5をまだ使用していないのであれば、その組み込み済みアプリケーションを使う際に必要とされるJavaのバージョンも同様に上げないと、その組み込み済みアプリケーションは使えないということになる。
1.4互換をやめJava5の機能を使うこと、そしてそれに加えてJRubyチームがアノテーションや列挙型のような新しい言語仕様を使うのを許すことに対する正当な論拠がある。ひとつはJava5に追加された先進的な同時並行ライブラリである。今すぐにjava.util.concurrentライブラリのbackport(source)がJRubyに含まれて出荷されたとしたら、そのことはダウンロードサイズが増加するということを意味する。またこのbackportは、Java5の同時並行サポートの特定なクラスを使えないので、ある機能はJava5のjava.util.concurrencyクラスと一緒に使用した場合と同じパフォーマンスを出す事は出来ない。
1.4互換を保つ大きな理由は、大企業の長いアップグレードサイクルである。それはソフトウェアのバージョン上で統一化しようと努める。しかし、Windows、MacOS XそしてLinuxという主要なプラットフォームを含め、ほとんどのプラットフォームがJava5をサポートしているので、Java5への移行に反対する理由は急速に減少している。Java 5がリリースされて3年、アーリアダプタにより問題が発見されたり報告されたりしたので、JVMやライブラリは成熟したのではないかと思われている。
先の理由と比べてより重要でない理由ではあるが、もう一つの1.4互換を保つ理由は、フリーライセンスのJava5完全互換実装が不足していることである。Apache Harmonyプロジェクトと同様にGNU Classpathmが完全互換のゴールへ近づいている間、他のJava5完全互換実装はまだゴールへ近づいていない。API完全性は少なくとも95%(source)であり、それらのプロジェクトにとっては偉業である。しかし依然として100%Java 5互換ではないのだ。Eclipseのような大きなアプリケーションが、フリーのJVM上で動く限り、小さな非互換性が現れ得る。そして非互換性は潜在的にサポート部門の頭痛の種となるだろう。
SunによるOpenJDKプロジェクトで、GPLライセンス下の完全なJavaを近い将来利用できなければならない。(Javaのいくつかの部分はGPLライセンス下でまだ利用できない点に注意してほしい。何故ならSunはGPLライセンスかで、それらを発表する権利を持っていないからである。(source))
リリースされたJRuby 1.0はJava 1.4互換であり、将来も1.4互換でありつづけるだろう。Java 5への移行は、将来リリースされるJRubyのために議論される。
このことに関するあなたの意見はいかがでしょう?1.4互換を維持する必要があるプロジェクトで働いているだろうか?もしそうであれば、会社の標準だからという以外の理由はあるのだろうか?
原文はこちらです:http://www.infoq.com/news/2007/07/jruby-java5-move
(この記事は2007年7月27日にリリースされました)
現在のRIAアーキテクチャにおいて、クライアント/サーバーの通信は重要な位置を占めています。本稿では、James WardとShashank TiwariがアドビによるオープンソースのBlazeDSメッセージングサーバーの世界へ飛び込みます。
ウィルス対策ソフトや情報漏えい防止用のソフトは、いわば影の存在です。ユーザの操作性やGUIを工夫する以上に、いかに目立たない存在となるかにその技術を注ぎ込んでいます。ここでは日立ソフトが開発した「秘文」の事例を紹介します。
Google Chartは、チャートを作成するためのWebサービスです。本稿では、Google Chartのインターフェースと、Rubyコードから簡単にチャートを生成することができるgchartrbライブラリの説明をします。
全二回からなるこの記事では、ダイナミックビジネスアプリケーション(Dynamic Business Applications:DBAs)の開発についての全体的な眺望を、アーキテクチャと方法論の観点から見ていくことになります。我々のゴールは、「ビジネスの変化や、その他に必要とされる変更に対して、いかにして容易に適応できるアプリケーションを構築していくか」を導きだすことです。
本稿では、Adrien Louis氏がESBベースのSOAに対する2つの接続形態についての賛否について説明しています。その2つとは、会社での単一のESB対「部門毎」に相互接続するESBによるシステムです。
誕生から2年を経てCometは「何が出来るのか」という議論から、「いかに実現するか」という議論に関心が移ってきたように見えます。そこで本稿では同じくJavaOneで数多く取り上げられたNetBeans 6.1とGlassFish v3を使いながら、サンプルを交えてCometを解説していく事にします。
この記事では、WSS3とMOSS 2007に難しい設定など一切せず、すぐに利用可能なWebサービスと、Javaと.NETからそのWebサービスを消費する方法に目を向けます。
この記事の始まりは、知的で思慮深い人たちの魅力的なグループが食事会を終えて話をしているところです。話はレトロスペクティブ(振り返り)プロセスの要であるプライムディレクティブ(最初の指示)に及んでいます。
No comments
返信