GNU Classpath
 |
 GNU Classpath Swing のデモ画面 | |
| 開発元 | GNUプロジェクト |
|---|---|
| 最新版 |
0.99
/ 2012年3月7日 |
| リポジトリ | |
| 対応OS | クロスプラットフォーム |
| サポート状況 | 終了 |
| 種別 | ライブラリ |
| ライセンス | 例外条項付きGPL |
| 公式サイト | http://www.classpath.org |
GNU Classpath は、かつて開発されていたJavaの標準クラスライブラリの自由ソフトウェアによる実装を作るプロジェクト、およびそのライブラリである。フリーソフトウェア財団のGNUプロジェクトの一部であった。作成すべきライブラリは膨大だったが、そのほとんどは完了しており、Swing、CORBAなども含まれていた。ClasspathではJ2SE 1.4および5.0の全クラスをほとんど実装していた。従ってClasspathをVuzeやEclipseといった一般的なJavaベースのソフトウェアで使うことができた。
その後、サン・マイクロシステムズ（現オラクル）によってOpenJDKがGPLライセンス下でオープンソースとしてリリースされ、Javaプラットフォームの公式リファレンス実装となったため、GNU Classpathプロジェクトはその役割を終え、2012年のバージョン0.99を最後に開発が終了した。
GNU Classpathはライセンス条件の違いがあるため、libgcjと並行して開発された。その後GPLを採用することで合意がなされ、両プロジェクトは統合された。
ライセンス
[編集]GNU Classpathは、リンクに関する例外付きのGPLの条件下でライセンス提供されていた。すなわち、オープンソースの自由ソフトウェアである。全コードは形式上フリーソフトウェア財団の所有となっており、その所有権は開発者たちとの契約上の義務によって束縛されていた。
Uses
[編集]GNU Classpathは多くのフリーなJava実装（Kaffe、SableVM、JamVM、CACAO、Jikes RVMなど）で採用されていた。というのも、Java仮想マシンを実装した際に標準クラスライブラリが必須であり、GPLライセンスとするには選択肢はあまりなかったためである。
他に以下のもので使われていた。
- GNU Compiler for Java (GCJ) はJavaのコードをネイティブな独立した（Java VMを必要としない）実行ファイルにコンパイルする機能を持っていた（のちにGCC本体から削除）。
- IKVM.NETはJavaと.NET Frameworkを結びつけるものである。
- JNodeはJavaアプリケーションが動作するオペレーティングシステムであり、Javaとアセンブリ言語だけで書かれている。
- JaosはOberon-2言語と結びついた特殊なJava VMであった[1]。
- Jupiter Projectはクラスタ上の分散コンピューティング向け仮想機械。Myrinetで128プロセッサを結合したマシンで動作していた[2]。
- IcedTeaプロジェクトの最初期において、OpenJDKに含まれていたプロプライエタリな要素の代替として使用されていた。
歴史
[編集]GNU Classpathの開発は5人の開発者が1998年に開始した。その後、他のプロジェクトとの合併を何回か経験している (Kaffe, libgcj)。かつて、GNU Classpathは独自の仮想マシン (Japhar) を提供していた。Classpathが標準ライブラリとして充実するにつれて他のプロジェクトで利用されることが多くなり、仮想マシンが使われなくなったため、Japharの開発は中止された。公式のJava 1.4 APIのほとんどを実装した後、プロジェクトはバグ修正を主に行うようになった。2006年10月24日、1.4で最後まで実装されていなかったクラスHTMLWriterの実装が完了した。開発速度（一日平均の追加コード行数で計算）は2006年になって最高潮に達した。その後、2012年3月7日リリースのバージョン0.99を最後に、開発活動は停止した。
GNU Classpathという名称はBradley M. Kuhnが初期の開発者Paul Fisherに示唆したものである。当時、Javaのフリーな実装にサン・マイクロシステムズの商標を付与することを強いることについて、コミュニティには大きな懸念があった。KuhnはJavaのライブラリの場所を指す$CLASSPATHという環境変数を名称に使ってはどうかと示唆したのである。$CLASSPATHは実際に使われる際にjava（例えば/usr/lib/java）という文字列を含むディレクトリのパス名に展開される。従って具体的にJavaという単語を使わずにそれを連想させることができるのである。Fisherらは$や全部大文字の名前を好まなかったため、Classpathに落ち着いた。
開発チーム
[編集]プロジェクトチームには70名の開発者がおり（うち、約20名が常時活動していた）、管理者が1名活動していた。管理者は法律面の対応をし、定期的なリリースの実行と品質管理にも関与していた。管理者はCVSへのアクセス許可も行っていた。
他のプロジェクトとは異なり、GNU Classpathには正式な階層構造がなかった。技術的に可能な者が可能なことをしており、明確な分担は存在しなかった。コード修正はまずディスカッションリストにパッチとして投稿され、問題があればそこで議論された。当時は毎日、5件から8件のパッチ投稿があった。
プロジェクトは独自のテストスイート (Mauve) を使っていた。175,000項目のテストが毎日実行され、公式のAPIと互換が保たれていることが確認されていた。
仮想マシンとの繋がり
[編集]GNU Classpathには、公式なJava APIネームスペースにあるクラス群があった。これらクラス内でネイティブコードにアクセスする必要が生じた場合、少数の "VM" クラス群が使われていた。VMクラス群は本来のクラス名の前にVMと付けたものである（VMObject、VMStringなど）。VMクラス群は他のコードとは分離して格納され、private属性と final属性を付与されていた。これらのクラスのメソッドにはnativeというキーワードが含まれ、サポートライブラリが必要であることを示していた。このようなライブラリはJava仮想マシンの側で用意していた。GNU Classpathが接続できるJava仮想マシンは、そのソースコードにアクセス可能で修正可能な場合であった。例えば、サン・マイクロシステムズの（当時のプロプライエタリな）仮想マシンはこの条件を満たしていなかったため、使えなかった。
Java 1.5の新言語機能サポート
[編集]バージョン 0.95以前、GNU Classpathリリースでは 2つのtarballがリリースされていた。一方はメインの開発ブランチであり、もう一方はより実験的なブランチであった。後者では総称型、列挙型、アノテーションといったJava 1.5の新機能が追加されていた。
バージョン 0.95からはJava 1.5の総称型のような追加機能はメインブランチに完全に統合された。Eclipseのコンパイラ (ecj) でJava 1.5のソースコードをバイトコードにコンパイルし、それをGCJでネイティブコードに変換することができた[3]。
サンのオープンソースコンパイラとのインタフェース
[編集]バージョン 0.95 から、GPLのオープンソースのjavacでGNU Classpathのランタイム (GIJ) とコンパイラ (GCJ) が利用可能となり、また、GNU Classpathのクラスライブラリやツールや例をjavac自身でコンパイル可能となっていた。
omg.org ドメインに由来するクラス
[編集]GNU Classpathは、フリーでないライセンスのコードやフリーでないライセンスのコードから自動的に生成されたコードを受理しなかった。標準Java APIにはomg.orgドメインのクラスが多数含まれており、これらはObject Management GroupがリリースしたIDLファイルから生成されたものであった。これらのファイルは改変が許されていないためフリーではなかった。そのため、GNU Classpathでは、OMGの公式仕様書を参照して、対応するクラスを一から手で書いた。従って、GNU Classpathのそれらのコードも他の部分と同様に、自由ソフトウェアとして利用可能であった。
関連項目
[編集]出典
[編集]- ↑ “Jaos - Project Overview”. Institute for Computer Systems, ETH Zurich. 2008年4月28日閲覧。
- ↑ “The Jupiter Project”. Tarek S. Abdelrahman. 2026年7月3日閲覧。
- ↑ “GNU Classpath 0.95 Announcement (2007-04-23)”. GNUプロジェクト. 2026年7月3日閲覧。