5 Java ポリシーを読んでみた

まえだこうへ い

5.1 Java ポリシーを読むハメになった経緯

初っ端からブチまけると、 実は Java ポリシーなんて読むつもりは毛頭なかったのです。 なぜなら私は Java なんて大嫌いだか らです。 長たらしいクラス名やメソッド名なんてみると、 身の毛もよだちます。 ちゃんと 80 バイトの幅に収めろよ、 って感じ です。 （わら

冗談^*2 はさ ておき、 なぜ読むことになったかと言うと、 実は別の目的がありました。 典型的な手段が目的になってしまった 例です。 ことの発端は、 友人と別件での活動で進捗管理が必要になったためです。 某所の PC は admin 権 限が与えられておらず、 好き勝手にソフトウェアを入れられません。 ですが、 プロジェクト管理用に GanttProject^*3 は ライセンス使用料無しで導入できるので、 これで管理するか、 ということにしました。 オープンソースソフ トウェアなので、 きっと Debian にもパッケージがあるに違いない、 と。 WBS を作り、 自宅で Debian に GanttProject を導入しようとしたら、 パッケージが無いではありませんか。 使えないとせっかく作っ た WBS も更新できず困ります。 そこで仕方ないので、 ITP してみることにしました。 ちょうど、 ま だ BTS へ投げたことも、 ITP もしたことがなく、 ある意味ちょうど良いきっかけなので ITP してみまし た^*4 。

で、 Debian Hack Cafe で、 岩松さんから「どうせなら Java Policy 読んで、 勉強会のネタにしる」 と言われた訳です。 特 に断る理由もなかったので、 やることにしてみました。 が、 ちょうど今回の Debian 勉強会と、 KVM の記 事^*5 の公 開が時期的に重なってしまったため、 締切り直前で勉強会資料の作成をやっています。 終わるのかな。 当日の事前配布資料に、 このネタが掲載されていればきっと間に合ったのでしょう。

ちなみに、 肝心の当初の目的ですが、 完全に置いてけぼりを喰らっています。 Java ポリシーの翻訳はもう少しで終わるので すが、 ITP した GanttProject の deb パッケージ化は未着手、 GanttProject で進捗管理する対象は友人が中心に進めているも の、 進捗は遅れ気味になっています。 巻き返ししなければ。

5.2 さて、 今回の本題。

前置きが長くなりましたが、 今回の本題は、 Java ポリシーについて調査してみたよ、 でした。 要約によれば、 背景説明、 ポリ シーの内容、 議論すべき問題点、 Java パッケージメンテナ向けのアドバイスであり、 Java 仮想マシン、 Java コンパイ ラ、 Java プログラム、 Java ライブラリをターゲットにしています。 以下、 各章ごとに要点をまとめてみま した。

5.3 1 章背景説明

要点は 2 つです。

• 特定の議題をより詳細に決める場合、 Debian ポリシーにはサブポリシーとして扱われる。
• コメントなどをするには、 java-common パッケージチームや、 Debian Java メーリングリストに投稿しる。

要は、 Java には固有の事情があるので、 Java ポリシーというサブポリシーで扱っているよ、 ということです。

5.4 2 章ポリシー

Java パッケージに対するポリシーをまとめています。 そのポリシーとは以下のものです。

• コンパイラ、 仮想マシン、 ランタイム用の仮想パッケージが作られます。
• 全 Java コードは、 Java バイトコードとして、 全アーキテクチャ向けに配布しなければなりません。
• 開発者向け (ライブラリ) とエンドユーザ向け (プログラム) の 2 つのカテゴリに分類されます。

5.4.1 仮想マシン

Java 仮想マシンをパッケージ化する際のポリシーです。 パッケージ名、 依存関係、 コマンド名を規定して ます。

• java-virtual-machine パッケージを提供し、 java-common パッケージに依存していなければなりません。
• ランタイム環境を配布することもできます。
• Java2 に準拠したランタイムをパッケージでは、 java2-runtime を提供すべきです。 ^*6
• Sun Java プログラムと互換性のあるコマンドラインであれば、 /etc/alternatives/java という名前にするべき です。
• 必要なランタイム環境を、 あらかじめ CLASSPATH に設定しておくべきです。
• JDK のようにコンパイラや仮想マシンのソースコードを提供する場合は、 コンパイラパッケージを xxxx-dev と命名しなさい。
• Java クラスの実装は、 ネイティブ言語を用いた処理系で、 実行時にロードされる動的ライブラリとしてコンパ イルされ、 配置されています。 仮想マシンがネイティブコードをサポートする場合は、 動的ライブラリの検索 パスに/usr/lib/jni ディレクトリを設定しないといけません。

5.4.2 コンパイラ

Java コンパイラに関するポリシーです。 仮想マシンの時と基本的には同じで、 3 点挙げられています。

• java2-compiler パッケージを提供し、 java-common パッケージに依存していなければなりません。
• Sun JDK の javac と互換性があるなら、 /etc/alternatives/javac という名前にすべきです。
• コンパイルに必要な java コアクラスを CLASSPATH に設定しておくべきです。

5.4.3 Java プログラム

Java のプログラムに関するポリシーです。

• /usr/bin 以下に配置し、 実行可能でなければなりません。
• プログラムは binfmt_misc を使用した Java クラスか、 あるいはラッパーでも構いません。
• 特定の環境変数^*7 が なくても、 実行できなければなりません。
• 実行ファイルに関するポリシールールに従う必要があります。
• プログラム自体が補助クラスの場合は、 /usr/share/java ディレクトリ配下に jar ファイルとして配置しなけれ ばなりません。
• プログラム自体は仮想マシン (java-virtual-machine) とランタイム環境 (java2-runtime) に依存していなけれ ば な り ま せ ん 。
• プログラムの名前規則は無く、 ユーザ視点で一般的なプログラムです。

5.4.4 Java ライブラリ

Java ライブラリに関するポリシーです。 Java ならではで特徴的なことは、 開発者向 け^*8 や ユーザ向けのバージョンには分かれていないという点です。

• Java では開発者向けとユーザ向けとでライブラリのバージョンを分けません。 意味がないからです。
• Java ライブラリパッケージは、 libXXX[version]-java という形式の名前でなければなりません。
• version 部分はオプションで、 必要な部分だけを含むべきです。
• version 部分は名前の衝突を避けるようにすべきです。
• XXX は実際のパッケージ名です。
• jar アーカイブのクラスは、 /usr/share/java 配下に配置しなければなりません。
• 名前は package[-extraname]-fullversion.jar の形式です。
• extraname はオプションで、 パッケージで提供されている jar とは別に分けるためにパッケージ内部で使われ ます。
• fullversion は jar ファイルのバージョンです。 パッケージとは同一ではない場合があります。
• Java ライブラリはランタイム環境には依存しなければなりませんが、 仮想マシンには依存すべきではありま せん。

など。

5.4.5 main, contrib, non-free

main, contrib, non-free に分類するためのポリシーです。

• ソースパッケージが non-free なツールでしか (正しく) コンパイルできないなら^*9 、 main にすることはできません。 パッケージ自体が自由であるなら、 contrib に入れなければなりません。
• バイナリパッケージが non-free の仮想マシンだけで動くことができるなら^*10 、 main にすることはできません。 パッケージ自体が自由であるなら、 contrib にしなければなりません。

5.5 議論すべき問題

現在、 8 つほどの問題が取り上げられています。 いずれも議論の余地があるとのことです。

• リポジトリの名前と存在について。 最新バージョンでは削除されています。
• /usr/share/java におけるシンボリックリンクを C 言語のライブラリのようにスクリプトで置き換えるべきか 否か。
• コアクラスの必要性について。
• Sun のコミュニティーソースライセンスは、 Debian では使えるのか？使う場合はどうすれば良いのか
  item すべての jar ファイルは適切な CLASSPATH ドキュメントが必要です。

以下、 省略。

5.6 Java パッケージ作成者向けのアドバイス

Java パッケージ作成者向けのアドバイス、 とはなっているものの、 実際のところは、 足りないツールを作ってくれだとか、 他 の言語向けパッケージ作成では自動で行っている部分を手動でやれ、 といった話になっています。 しかもひどいことに、 「これ はアドバイスに過ぎず、 ポリシーの一部ではない」 と言っています。

• debian/control のすべての依存関係を手動で管理しなければなりません。 Debian の開発ツールでは Java のプ ログラムを検出することができません。
• だから、 Perl のように dh_java プログラムを作ってくれるボランティアは大歓迎とのこと。
• debian/rules の中の、 dh_strip や dh_shlibdeps のような Java には無意味なコマンドを無効にしましょう。

などです。

5.7 まとめ

実は、 ポリシーマニュアルをちゃんと読んだことがまだないので、 通常のポリシーに比べた場合の、 Java ポリシー の特徴がどうなのかがよく分かりません。 ただ、 自由なコンパイラが 3 つあるとか、 main に入れるための 制約とか、 命名規約やら、 依存関係についてのポリシーがあることを知りました。 これを元に途中で止まっ ていた ganttproject の deb パッケージ化を進めます。 またプロセスは、 本来の目的を達成するために早く 進めなきゃです。 ついでに、 今回訳した文章は、 取り合えず debian-doc に投げて査読してもらおうと思い ます。

5.8 今月のヨメ八苦

最近は、 毎週水曜の Hack Cafe は認めてもらえるようになりました。 まあ、 本人もその時間にジムに行けるからという理由も ありますが。 しかし、 IRC 会議や Debian 勉強会以外で、 Debian 絡みの作業したり、 外にでかけると、 「また Debian ？」 と怪 訝な顔をされます…。 なかなか思うとおりにはならんものです。

第 51 回東京エリア Debian 勉強会 2009 年 4 月
____________________________________________________________________________________________