OpenOffice.org 2.0ベータでは、いくつかの新機能でJava Runtime Environment(JRE)を必要としているが、そのことに対して、少数でも明確に発言する人々が激しくかつ否定的に反応している。
先日リリースされたOpenOffice.org 2.0ベータでは、いくつかの新機能でJava Runtime Environment(JRE)が必要になっている。Javaのライセンスはフリーでもオープンソースでもないので、少数でも明確に発言する人々が激しくかつ否定的に反応している。
例えば、先日NewsForgeはこのベータのレビューを発表したが、それ以外の部分にはそれほど関心が寄せられなかった。主要なGNU/Linuxディストリビューションのメンバーも含め、一部のグループ(そのほとんどがOpenOffice.orgを再パッケージ化している)は代わりになるものを探すという反応を示した。OpenOffice.org(OOo)のせいで余計な仕事が増えたことをののしりながら。OpenOffice.orgはなぜJavaに依存することになったのか。これによってどんな問題が起こり得るか。GNU/Linuxディストリビューションはソフトウェアの重要部分におけるこうした変更にどう対応するのか。 この決定は、実際的な検討に基づくところが大きく、その際、ほかのフリー/オープンソースソフトウェア(FOSS)コミュニティー、そしてOpenOffice.org自体の将来、この両方への影響は重く見られなかったようである。
この問題を理解するには、具体的にどの機能がJavaに依存しているかを知ることが重要だ。バージョン1.1.4の時点では、以下の機能がJREを必要条件としていた。
OpenOffice.orgのメンバーの中には少しでもJavaが使用されることに懸念を示す者もいたが、多くは、これらの機能がコア機能に影響せず、一部の少数ユーザーにしか関係しないという論拠を受け入れた。
OpenOffice.orgのリーダーたちは、バージョン2.0でもこの論拠を主張している。だが、バージョン2.0ではJava依存が増えた。以前からJavaに依存していた機能に加え、バージョン2.0では新たに以下の機能がJREを必要条件としている。
基本的なオフィス機能には影響しないという人もいるだろうが、2.0のほとんどのユーザーにとってJavaは必要ないといったら言いすぎになるだろう。
Javaなしでこのベータを実行しようとするなら、ますます無理な話になる。バージョン2.0がJREにリンクしていないときでも、JREを必要とするツールがメニューに表示され、どれがそういうツールかは試してみないと分からない。非Javaユーザーがこれらを試せば、一貫性のないさまざまな警告を受けることになる。新しいデータベースをJavaなしで構築しようとすれば、何の説明もなくダイアログウィンドウが閉じてしまう。Mailと電子メールのマージを試そうとすれば、それにはJava Mailが必要だというメッセージがポップアップダイアログではなく標準ウィンドウに表示される。最も困るのは、[Tools] > [Macro] > [Run Macro]を選択すると警告ダイアログが16回も表示され、全部表示するまで先に進めないことだ。OpenOffice.orgの機能に共通インタフェース標準が絶対的に必要だということはさておき、ほとんどのユーザーがJavaを有効にすることを前提に2.0がデザインされていることは、こうしたことからもはっきりしている。
多くの人にとっては、OpenOffice.orgコードのかつての所有者で、多くのOOoのプログラマーの勤務先であるSun Microsystems社がJavaの所有者でもあるというだけで、OpenOffice.orgの新たなJava依存の説明がつく。陰謀説も多々あるが、まともな論評によればOpenOffice.orgはSunとのつながりから単にJavaソリューションを受け入れやすいだけだという。どのプログラミング言語を使うかはコントリビューターたち自身が決めることだが、ほかのプロジェクトのときからの習慣が、特に反対の指示もないままOpenOffice.orgの仕事にも反映されたようだ。
だが、OpenOffice.orgのリーダーたちは、この決定を便宜的、技術的な利点によるものだという。その論拠のほとんどがBaseに関することで、この新しいデータベースアプリケーションは既存のJavaデータベースHSQLDBにAccess風のインタフェースを追加する。
OpenOffice.org Community Councilのコミュニティーコントリビューター代表であるダニエル・カレラ氏は、Base HSQLDBは「非常に限られたリソース条件下で統合可能なデータベースのうち最も高速で最も機能が揃っていた」という。また、OpenOffice.orgのC++コアはBase導入後も変わっていないという。したがって、Baseはあとで容易に置き換え可能だ。
Sunの社員でこのデータベースプロジェクトのリーダーであるFrank Sch・heit氏は、さらに詳しく説明している。「HSQLDBがJavaで書かれているということはこの決定の理由ではない」という。だが、プランニングの際には「HSQLDBがJavaだからといってそれが不利な条件にはならなかった」といっている。
Sch・heit氏は同時に、次の点を挙げてJavaの使用を弁護した。
JavaではOpenOffice.orgのコンポーネントを迅速に開発でき、OpenOffice.orgのC++ビルド環境の複雑さに悩まないで済む。
Javaは複雑な作業への使用に耐えるくらい十分に成熟している。
よく信じられている先入観に反し、Javaは本質的に遅くない。Javaではパフォーマンスの悪いコードも容易に書けてしまうので、Javaコードを書く開発者はもっと自己鍛錬が必要だろう。だが、このこと自体はJavaの本質的な問題ではない。
これらの利点の威力は、この新しいデータベースをオープンソースにするというデータベースチーム自体の要件さえも無視してしまうほど大きかった。Sch・heit氏は、OpenOffice.orgのプログラマーは「Javaがオープンソースかどうかをそれほど問題にはしていない」という。プログラマーたちはJavaで書かれたコードよりC++で書かれたコードを使う方を好むものだが(たとえC++コードの方が多少劣っていても)、それでもJavaの方が優れたソリューションであればJavaを使う。「また単に、プロジェクトに時間を費やすことができるJava開発者はいても、それができるC++開発者がいないという場合もあるのです」Sch・heit氏は、最終的に重要なのは「OpenOffice.org 2.0に独自のデータベースが備わるということです……。わたしたちにとってはそれが、すべてといわないまでもほとんどのJava反対論を凌駕します。そういう意味で機能が大切なのです」と書いている。
Copyright © 2010 OSDN Corporation, All Rights Reserved.