 |
| 開発元 | Apacheソフトウェア財団 |
|---|---|
| 最新版 |
5.0M15 6.0M3 / 2010年9月2日 |
| リポジトリ | |
| プラットフォーム | クロスプラットフォーム |
| サポート状況 | 開発終了 |
| 種別 | Java SE |
| ライセンス | Apache License |
| 公式サイト |
harmony |
Apache Harmony（アパッチ・ハーモニー）は、オープンソースかつフリーなJava実装である。Java SE 5, 6を元にしており、Apache License Version 2 にて提供されていた。開発は2005年5月に開始され、2006年10月にはApache財団のトップレベルプロジェクトとなった。しかし別のオープンソース実装であるOpenJDKに集約される形となり、2011年11月3日に開発終了した。
SDKやJREも配布されており、仮想マシンにはDRLVMを、コンパイラにはEclipse Java Compilerを使用していた。
HarmonyプロジェクトはフリーなJava実装の開発者たちを統括する動きと捉えられていた。多くの開発者はこの動きがApache, GNU等のプロジェクトとして纏まると期待していた。まずGNU開発者がプロジェクトの立ち上げ準備に関わったが、後にHarmonyではGNU Classpathのコードは利用しないと決定した。ライセンス互換上の問題で、Harmonyと他プロジェクト間でのコードの共有が難しくなるという問題があったためである。Apache開発者たちは必要なクラスをスクラッチから書き始め、またソフトウエア会社からコードの寄贈を募集した。
GNU ClasspathとApacheプロジェクトが袂を分かったのは、GPLとApacheライセンスの違いにある。多くの組織や個人がこの相違点を取り上げ、派生物には公開義務が無いApacheライセンスの適用を望むとの意見が寄せられた。GNU Classpathは独占的ソフトウエアとのリンクは可能だが、GNU Classpath自身の非公開派生物を作成するのは法的に困難なためである。
しかし、いくらかのフリーソフトウエア開発者は、これらのライセンスやコミュニティ哲学の違いは別個に実装を行うまでは違わず、妥協点を探せなくはないと頻繁に否定的な意見を述べている。だが、時折現れるこういったプロジェクトへの反対的な提案は幅広い支持を得ていない。フリーソフトウエア支持者は以下の単純な言葉でこれを切って捨てている。"more free software is not a problem（フリーソフトウエアが多いことは問題ではない）".
2007年4月10日、Apache財団 (ASF) はサン・マイクロシステムズ（サン）のCEO、ジョナサン・シュワルツ宛にJava SE 5 テクノロジ互換キット (TCK) についての公開書簡を送った。TCKのライセンスはHarmonyユーザに利用範囲の制限を課すものでJCPのルールに反しているから、ASFにとって承諾しがたいものであると主張している。
サンは企業のブログ上で回答し、TCKを含めJavaのオープンソース実装プラットフォームをGPLで提供したいが、まずはGNU/Linuxコミュニティに対してJavaプラットフォームのGPL提供を優先するとした。 このやりとりは一部からオープンなやり方ではないとサンやASFは批評を受けたが、結果的にはクラスライブラリ開示のスケジュールを考えると、より多くの提供をサンから受けることを目的にASFは強気に振舞ったのだと考える人もいた。
立ち上がるとすぐに、プロジェクトは既に開発に着手していたいくつかの会社から大きなコード寄贈を受けて動き出した。しかしながらメーリングリスト上での全般的な議論は常に開かれていた。
その後、プロジェクトにはASF管理者によりアパッチ流の開発方式を取り入れたことにより、大きく成功したといえるだろう。2006年11月時点で、プロジェクトチームのコミッターは16人の開発者及び、IBMとインテルに属する16の開発チームで構成されていた。
2006年10月、Apache HarmonyプロジェクトはApache財団の公式プロジェクト (Top level Projects) に昇格された。
当初期待したソフトウエア会社からのコード寄贈は現実のものとなっていた。Apache Harmonyの作業コードにはインテルより寄贈された Swing、AWT、Java 2Dのコードが加えられた。
クラスの実装については、2010年9月20日時点で (5.0M15, 6.0M3)、Java SE 5の99.00%、Java SE 6の97.54%が実装（クラス・メソッド・フィールドとして存在）されていた。
また、HarmonyのテストスィートはGNU Classpathと比べてより厳密なものとなっていた（2006年10月の時点で、GNU Classpathは20000 tests 、Harmonyは 50000 である）。
Harmonyプロジェクトの進捗はJ2SE 1.4とJava SE 5.0を追っている状態であり、Harmony v6.0はJava SE 6.0の別ブランチと見なす事ができるほどであった。
文書化については、Harmonyは他のフリーのJava実装より整備が進んでいない状態にあった。 たとえば、GNU Classpathでは中心的なCORBAのクラス (ORB) の各メソッドに関して、 抽象APIクラスと実装クラスについて説明のコメントが付いている。Harmonyで使用されているYokoプロジェクトでは、大半のメソッドについて 標準の宣言および実装クラスのドキュメント化がされていなかった（2006年10月時点）。また、GNU Classpathは、（Sunの実装同様）CORBAの機能について古いものと現在のものの両方をサポートしている。Harmonyでは、古い規格に基づく代表的なメソッド (ORB.connect(Object)) が全く実装されていないままであった。
Javaプラットフォームの完全な実装には、たとえばJavaソースコードをバイトコードに変換するコンパイラ、Jarファイルを管理するプログラム、デバッガ、アプレットビューアー、ウェブブラウザプラグインなどが必要である。Harmony ではコンパイラのみが実現されていた。
Harmonyは、いずれも外部からの寄付による4種類のJava仮想マシン実装をサポートしていた。
2006年11月の時点でこれらの仮想マシンによる言語のサポートは完全ではなかったため、クラスライブラリのテストを実行するためのビルドの手順として IBMのプロプライエタリなVMであるJ9を使うよう推奨されていたが、2007年7月時点ではJ9は不要となっていた。
DRLVM仮想マシンの開発が積極的に進んでおり（2006年7月時点）、進展が期待できる状態にあった。
構想の時点から、Harmonyは重要なJavaアプリケーション（リンク参照）を実行する能力を着実に向上させてきた。2007年7月の時でたとえば下記のアプリケーションがサポートされていた。
しかし、Harmonyのライブラリ実装が不完全であるため、実行できないアプリケーションもあった。
.svg){kind=logo}
