Java パッケージガイドライン - 版の履歴

Kgx: 他言語へのリンクを追加

2023-06-28T13:23:43Z

他言語へのリンクを追加

← 古い版		2023年6月28日 (水) 22:23時点における版
2行目:		2行目:
	[[en:Java package guidelines]]		[[en:Java package guidelines]]
	[[it:Java package guidelines]]		[[it:Java package guidelines]]
			[[pt:Java package guidelines]]
	[[zh-hans:Java package guidelines]]		[[zh-hans:Java package guidelines]]
	{{Package Guidelines}}		{{Package Guidelines}}
7行目:		8行目:
	この文章では Arch Linux における [[Java]] プログラムのパッケージングについて提唱される標準を定義しています。Java プログラムは依存関係を重ねないようにパッケージ化するのが大変難しいことで有名です。この文章ではそれをなんとか改善する方法を説明します。Java アプリケーションを扱うときは様々な場面に合わせて以下のガイドラインを臨機応変に読み替えてください。		この文章では Arch Linux における [[Java]] プログラムのパッケージングについて提唱される標準を定義しています。Java プログラムは依存関係を重ねないようにパッケージ化するのが大変難しいことで有名です。この文章ではそれをなんとか改善する方法を説明します。Java アプリケーションを扱うときは様々な場面に合わせて以下のガイドラインを臨機応変に読み替えてください。

	==イントロダクション==		== イントロダクション ==

	Java パッケージの処理方法について Arch Linux のパッケージ作成者が合意を取ることは不可能です。公式・非公式リポジトリや [[AUR]] に存在する [[PKGBUILD]] では様々な手段が使われています。{{Ic\|/opt}} に全てのファイルを配置して、{{Ic\|/usr/bin}} にシェルスクリプトを置いたり {{Ic\|/etc/profile}} にプロファイルを保存する方法もあれば、{{Ic\|/usr/share}} のディレクトリにファイルを配置して {{Ic\|/usr/bin}} にスクリプトを置いているのもあります。システムの {{Ic\|CLASSPATH}} や {{Ic\|PATH}} には多くの不必要なファイルが追加されています。		Java パッケージの処理方法について Arch Linux のパッケージ作成者が合意を取ることは不可能です。公式・非公式リポジトリや [[AUR]] に存在する [[PKGBUILD]] では様々な手段が使われています。{{Ic\|/opt}} に全てのファイルを配置して、{{Ic\|/usr/bin}} にシェルスクリプトを置いたり {{Ic\|/etc/profile}} にプロファイルを保存する方法もあれば、{{Ic\|/usr/share}} のディレクトリにファイルを配置して {{Ic\|/usr/bin}} にスクリプトを置いているのもあります。システムの {{Ic\|CLASSPATH}} や {{Ic\|PATH}} には多くの不必要なファイルが追加されています。

	==典型的な Java アプリケーションの構造==		== 典型的な Java アプリケーションの構造 ==

	ほとんどの Java のデスクトップアプリケーションは同じような構造をしています。これらのアプリケーションはシステムに依存しない (ただしパッケージに依存する) インストーラーによってインストールされます。大抵は全てを単一のディレクトリにインストールして {{Ic\|bin}}, {{Ic\|lib}}, {{Ic\|jar}}, {{Ic\|conf}} などのサブディレクトリが作られます。通常、メインの jar ファイルが存在していて、メインの実行クラスが記述されています。また、Java インタプリタを直接実行しなくてもいいように、メインクラスを実行するためのシェルスクリプトも付属しているのが普通です。シェルスクリプトは様々なディストリビューションで共通して用いられ、別の環境 (例: Cygwin) 用の特殊なケースもカバーするようになっている場合が多く、非常に複雑になっています。		ほとんどの Java のデスクトップアプリケーションは同じような構造をしています。これらのアプリケーションはシステムに依存しない (ただしパッケージに依存する) インストーラーによってインストールされます。大抵は全てを単一のディレクトリにインストールして {{Ic\|bin}}, {{Ic\|lib}}, {{Ic\|jar}}, {{Ic\|conf}} などのサブディレクトリが作られます。通常、メインの jar ファイルが存在していて、メインの実行クラスが記述されています。また、Java インタプリタを直接実行しなくてもいいように、メインクラスを実行するためのシェルスクリプトも付属しているのが普通です。シェルスクリプトは様々なディストリビューションで共通して用いられ、別の環境 (例: Cygwin) 用の特殊なケースもカバーするようになっている場合が多く、非常に複雑になっています。

	{{Ic\|lib}} ディレクトリには jar ファイルがバンドルされているのが通例で、Java アプリケーションの依存関係を満たすようになっています。(全ての依存パッケージが含まれていることは) プログラムをインストールしたいユーザーにとっては楽ですが、パッケージの開発者にとっては悪夢です。同一の依存パッケージを複数のパッケージがバンドルしていることは無駄に他なりません。Java のデスクトップアプリケーションやライブラリの数が少なかった昔はそこまで大きな問題ではありませんでしたが、Java アプリケーションとライブラリの数が増えるにつれて避けがたい問題になっています。時代は変わったのです。		{{Ic\|lib}} ディレクトリには jar ファイルがバンドルされているのが通例で、Java アプリケーションの依存関係を満たすようになっています。(全ての依存パッケージが含まれていることは) プログラムをインストールしたいユーザーにとっては楽ですが、パッケージの開発者にとっては悪夢です。同一の依存パッケージを複数のパッケージがバンドルしていることは無駄に他なりません。Java のデスクトップアプリケーションやライブラリの数が少なかった昔はそこまで大きな問題ではありませんでしたが、Java アプリケーションとライブラリの数が増えるにつれて避けがたい問題になっています。時代は変わったのです。

	プログラムを実行するのに必要な他のファイルはメインの jar ファイルと同じフォルダに保存されるか、サブディレクトリに保存されるのが普通です。Java プログラムはどこからクラスがロードされたか関知しないので、jar ファイルがあるディレクトリ内から実行しなくてはなりません (シェルスクリプトでディレクトリに {{Ic\|cd}} する必要がある)。あるいは、ディレクトリの場所を示す環境変数を設定します。		プログラムを実行するのに必要な他のファイルはメインの jar ファイルと同じフォルダに保存されるか、サブディレクトリに保存されるのが普通です。Java プログラムはどこからクラスがロードされたか関知しないので、jar ファイルがあるディレクトリ内から実行しなくてはなりません (シェルスクリプトでディレクトリに {{Ic\|cd}} する必要がある) あるいは、ディレクトリの場所を示す環境変数を設定します。

	==パッケージング==		== パッケージング ==

	Arch で Java アプリケーションをパッケージ化するのは骨の折れる作業です。しかしながら、上手くパッケージ化することでファイルシステムをきれいにして同梱する依存ライブラリを減らせます (Java ライブラリがパッケージとして作り直されることで、パッケージ化も楽になります)。Arch Linux の Java パッケージを作成するときは以下のガイドラインに従ってください:		Arch で Java アプリケーションをパッケージ化するのは骨の折れる作業です。しかしながら、上手くパッケージ化することでファイルシステムをきれいにして同梱する依存ライブラリを減らせます (Java ライブラリがパッケージとして作り直されることで、パッケージ化も楽になります)。Arch Linux の Java パッケージを作成するときは以下のガイドラインに従ってください:

Kgx: /* パッケージング */ 翻訳

2023-06-28T13:22:03Z

パッケージング: 翻訳

← 古い版		2023年6月28日 (水) 22:22時点における版
18行目:		18行目:

	==パッケージング==		==パッケージング==

	Arch で Java アプリケーションをパッケージ化するのは骨の折れる作業です。しかしながら、上手くパッケージ化することでファイルシステムをきれいにして同梱する依存ライブラリを減らせます (Java ライブラリがパッケージとして作り直されることで、パッケージ化も楽になります)。Arch Linux の Java パッケージを作成するときは以下のガイドラインに従ってください:		Arch で Java アプリケーションをパッケージ化するのは骨の折れる作業です。しかしながら、上手くパッケージ化することでファイルシステムをきれいにして同梱する依存ライブラリを減らせます (Java ライブラリがパッケージとして作り直されることで、パッケージ化も楽になります)。Arch Linux の Java パッケージを作成するときは以下のガイドラインに従ってください:

26行目:		27行目:
	* プログラムと一緒に配布されている jar ファイルは全て {{Ic\|/usr/share/java/myprogram}} ディレクトリに配置してください。アプリケーションの依存ライブラリとして配布されている jar ファイルも含みます。ただし、一般的に使われるライブラリや巨大なライブラリ群は独立した別のパッケージとするべきです。プログラムが特定のバージョンのライブラリに依存しない場合にこれが当てはまります。		* プログラムと一緒に配布されている jar ファイルは全て {{Ic\|/usr/share/java/myprogram}} ディレクトリに配置してください。アプリケーションの依存ライブラリとして配布されている jar ファイルも含みます。ただし、一般的に使われるライブラリや巨大なライブラリ群は独立した別のパッケージとするべきです。プログラムが特定のバージョンのライブラリに依存しない場合にこれが当てはまります。

			: このルールにより、依存関係を反復的にリファクタリングできるようになります。つまり、パッケージとそのすべての依存関係を最初に 1 つのディレクトリに配置できます。これをテストした後、主要な依存関係を一度に 1 つずつリファクタリングできます。一部のアプリケーションには、メインの jar ファイル内にバンドルされた依存関係が含まれていることに注意してください。つまり、バンドルされた依存関係を解凍し、メインの jar に含めます。このような依存関係は通常非常に小さいため、リファクタリングする意味はほとんどありません。
	: This rule makes it possible to iteratively refactor dependencies. That is, the package and all its dependencies can be placed into one directory at first. After this has been tested, major dependencies can be refactored out one at a time. Note that some applications include bundled dependencies inside the main jar file. That is, they unjar the bundled dependencies and include them in the main jar. Such dependencies are usually very small and there is little point in refactoring them.

	* ユーザーがプログラムを実行するようになっている場合、メインの jar ファイルを起動するカスタムシェルスクリプトを書いてください。実行スクリプトは {{Ic\|/usr/bin}} に配置します。ライブラリは基本的にシェルスクリプトを必要としません。プログラムに付属しているスクリプトを使うよりも、スクラッチからシェルスクリプトを書くことを推奨します。(Cygwin など) カスタム環境をテストするコードや、{{Ic\|JAVA_HOME}} が設定されているかどうか確認するコードは削除してください (Arch では {{ic\|JAVA_HOME}} を[[Java#インストール\|使用せず]]、{{ic\|archlinux-java}} を使って {{ic\|/usr/bin/java}} シンボリックリンクを設定します)。		* ユーザーがプログラムを実行するようになっている場合、メインの jar ファイルを起動するカスタムシェルスクリプトを書いてください。実行スクリプトは {{Ic\|/usr/bin}} に配置します。ライブラリは基本的にシェルスクリプトを必要としません。プログラムに付属しているスクリプトを使うよりも、スクラッチからシェルスクリプトを書くことを推奨します。(Cygwin など) カスタム環境をテストするコードや、{{Ic\|JAVA_HOME}} が設定されているかどうか確認するコードは削除してください (Arch では {{ic\|JAVA_HOME}} を[[Java#インストール\|使用せず]]、{{ic\|archlinux-java}} を使って {{ic\|/usr/bin/java}} シンボリックリンクを設定します)。
38行目:		39行目:
	exec /usr/bin/java '/usr/share/java/PROGRAMNAME/PROGRAMCLASSNAME' "$@"</nowiki>}}		exec /usr/bin/java '/usr/share/java/PROGRAMNAME/PROGRAMCLASSNAME' "$@"</nowiki>}}

			* 明示的な理由がない限り、{{Ic\|-cp}} オプションを使用して {{Ic\|CLASSPATH}} を Java インタープリタに設定します (つまり、{{Ic\|CLASSPATH}} はプラグインメカニズムとして使用されます) ){{Ic\|CLASSPATH}} には、{{Ic\|/usr/share/java/myprogram}} ディレクトリ内のすべての jar ファイルに加えて、他のディレクトリにリファクタリングされた依存関係ライブラリの jar ファイルも含める必要があります。次のコードのようなものを使用できます。
	* Set the {{Ic\|CLASSPATH}} using the {{Ic\|-cp}} option to the Java interpreter unless there is an explicit reason not to (ie: the {{Ic\|CLASSPATH}} is used as a plugin mechanism). The {{Ic\|CLASSPATH}} should include all jar files in the {{Ic\|/usr/share/java/myprogram}} direcory, as well as jar files that are from dependency libraries that have been refactored to other directories. You can use something like the following code:
	:{{Bc\|<nowiki>for name in /usr/share/java/myprogram/*.jar ; do		:{{Bc\|<nowiki>for name in /usr/share/java/myprogram/*.jar ; do
	CP=$CP:$name		CP=$CP:$name
45行目:		46行目:
	java -cp $CP myprogram.java.MainClass</nowiki>}}		java -cp $CP myprogram.java.MainClass</nowiki>}}

			* シェルスクリプトが実行可能であることを確認してください。
	* Make sure the shell script is executable!

			* パッケージとともに配布されるその他のファイルは、{{Ic\|/usr/share}} の下のパッケージにちなんで名付けられたディレクトリに保存する必要があります。シェルスクリプト内の {{Ic\|MYPROJECT_HOME}} のような変数にこのディレクトリの場所を設定する必要がある場合があります。このガイドラインは、プログラムがすべてのファイルが同じディレクトリにあることを期待していることを前提としています (Java パッケージの標準と同様) 設定ファイルを別の場所に置いたほうが自然だと思われる場合 (たとえば、ログを {{Ic\|/var/log}} に置くなど)、してください。
	* Other files distributed with the package should be stored in a directory named after the package under {{Ic\|/usr/share}}. You may need to set the location of this directory in a variable like {{Ic\|MYPROJECT_HOME}} inside the shell script. This guideline assumes that the program expects all files to be in the same directory (as is standard with Java packages). If it seems more natural to put a configuration file elsewhere (for example, logs in {{Ic\|/var/log}}), then feel free to do so.

	: 環境によっては {{Ic\|/usr}} は読み取り専用でマウントされる場合もあるので注意してください。アプリケーションによる書き込みが必要なファイルが共有ディレクトリに存在する場合、{{Ic\|/etc}} や {{Ic\|/var}}、あるいはユーザーのホームディレクトリに再配置できないか確認してください。		: 環境によっては {{Ic\|/usr}} は読み取り専用でマウントされる場合もあるので注意してください。アプリケーションによる書き込みが必要なファイルが共有ディレクトリに存在する場合、{{Ic\|/etc}} や {{Ic\|/var}}、あるいはユーザーのホームディレクトリに再配置できないか確認してください。

			* Arch Linux パッケージの標準と同様、多大な労力を費やすことなく上記の標準に従うことができない場合は、パッケージを適切な方法でインストールし、その結果ディレクトリが {{Ic\|/opt}} に配置されるようにする必要があります。これは、JRE をバンドルするプログラム、依存関係のカスタマイズされたバージョンを含めるプログラム、またはその他の奇妙なタスクや面倒なタスクを実行するプログラムに役立ちます。
	* As is standard with Arch Linux packages, if the above standards cannot be adhered to without a serious amount of work, the package should be installed in its preferred manner, with the resulting directory located in {{Ic\|/opt}}. This is useful for programs that bundle JREs or include customized versions of dependencies, or do other strange or painful tasks.

		⚫	=== 複数の API 実装 ===

⚫	===複数の API 実装===
	一般的に使われる API 実装 (JDBC ドライバーなど) を配布するパッケージは {{Ic\|/usr/share/java/''apiname''}} にライブラリを配置してください。アプリケーションからユーザーが実装を選択できるようにするためです。{{Ic\|/usr/share/java/''apiname''}} を使用できるのはライブラリしか含まないパッケージだけです。アプリケーションの一部として実装が含まれる場合、通常のパッケージツリーと同じ場所に配置してください。		一般的に使われる API 実装 (JDBC ドライバーなど) を配布するパッケージは {{Ic\|/usr/share/java/''apiname''}} にライブラリを配置してください。アプリケーションからユーザーが実装を選択できるようにするためです。{{Ic\|/usr/share/java/''apiname''}} を使用できるのはライブラリしか含まないパッケージだけです。アプリケーションの一部として実装が含まれる場合、通常のパッケージツリーと同じ場所に配置してください。

	===ディレクトリ構造の例===		=== ディレクトリ構造の例 ===

	以下は {{Ic\|foo}} という仮のプログラムのディレクトリ構造の例です。{{Ic\|foo}} は一般的な名前なので、パッケージの名前は {{Ic\|java-foo}} としていますが、以下のディレクトリではその名前は使っていません:		以下は {{Ic\|foo}} という仮のプログラムのディレクトリ構造の例です。{{Ic\|foo}} は一般的な名前なので、パッケージの名前は {{Ic\|java-foo}} としていますが、以下のディレクトリではその名前は使っていません:

67行目:		70行目:

	===依存パッケージ===		===依存パッケージ===
	Java パッケージには、必要に応じて、{{Ic\|java-runtime}} あるいは {{Ic\|java-environment}} を依存パッケージとして指定します。

	~~大抵の~~パッケージでは、~~Java で書かれたソフトウェアを実行するの~~に {{Ic\|java-runtime}} ~~が必要になり~~ます。{{Ic\|java-~~runtime~~}} ~~は以下のパッケージに含~~ま~~れている仮想パッケージで~~す:		Java パッケージは、必要に応じて、依存関係として {{ic\|java-runtime}} または {{ic\|java-environment}} を指定する場合があります。

			ほとんどのパッケージでは、Java で書かれたソフトウェアを単純に実行するために必要なものは {{ic\|java-runtime}} です。
	* {{Pkg\|jre8-openjdk}} (フリー)
	* {{Pkg\|jre7-openjdk}} (フリー)
	* {{AUR\|java-gcj-compat}} (フリー)
	* {{AUR\|jre}} (ノンフリー)

	Java のソースコードをバイトコードにコンパイルする必要があるパッケージで~~は {{Ic\|java-environment}} (例: JDK) が必須になりま~~す。~~{{Ic\|java-environment}} は以下のパッケージに含まれている仮想パッケージです:~~		{{ic\|java-environment}} (JDK など) は、Java ソースコードをバイトコードにコンパイルする必要があるパッケージに必要です。

			詳細については、[[Java]] を参照してください。
	* {{Pkg\|jdk8-openjdk}} (フリー)
	* {{Pkg\|jdk7-openjdk}} (フリー)
	* {{AUR\|jdk}} (ノンフリー)

Kusakata: 同期

2017-12-03T14:19:21Z

同期

← 古い版		2017年12月3日 (日) 23:19時点における版
24行目:		24行目:
	* Java アプリケーションをソースからコンパイルする必要はありません。gcc で作成されたバイナリと同じように、コンパイルによって得られる最適化は僅かです。ソースからビルドする簡単な方法がソースパッケージに用意されている場合はそれを使ってかまいませんが、バイナリリリースの jar ファイルやインストーラーを取得するほうが簡単な場合はそれで結構です。		* Java アプリケーションをソースからコンパイルする必要はありません。gcc で作成されたバイナリと同じように、コンパイルによって得られる最適化は僅かです。ソースからビルドする簡単な方法がソースパッケージに用意されている場合はそれを使ってかまいませんが、バイナリリリースの jar ファイルやインストーラーを取得するほうが簡単な場合はそれで結構です。

			* プログラムと一緒に配布されている jar ファイルは全て {{Ic\|/usr/share/java/myprogram}} ディレクトリに配置してください。アプリケーションの依存ライブラリとして配布されている jar ファイルも含みます。ただし、一般的に使われるライブラリや巨大なライブラリ群は独立した別のパッケージとするべきです。プログラムが特定のバージョンのライブラリに依存しない場合にこれが当てはまります。
	* Place all jar files (and no other files) distributed with the program in a {{Ic\|/usr/share/java/myprogram}} directory. This includes all dependency jar files distributed with the application. However, effort should be made to place common or large dependency libraries into their own packages. This can only happen if the program does not depend on a specific version of a dependency library.

	This rule makes it possible to iteratively refactor dependencies. That is, the package and all its dependencies can be placed into one directory at first. After this has been tested, major dependencies can be refactored out one at a time. Note that some applications include bundled dependencies inside the main jar file. That is, they unjar the bundled dependencies and include them in the main jar. Such dependencies are usually very small and there is little point in refactoring them.		: This rule makes it possible to iteratively refactor dependencies. That is, the package and all its dependencies can be placed into one directory at first. After this has been tested, major dependencies can be refactored out one at a time. Note that some applications include bundled dependencies inside the main jar file. That is, they unjar the bundled dependencies and include them in the main jar. Such dependencies are usually very small and there is little point in refactoring them.

			* ユーザーがプログラムを実行するようになっている場合、メインの jar ファイルを起動するカスタムシェルスクリプトを書いてください。実行スクリプトは {{Ic\|/usr/bin}} に配置します。ライブラリは基本的にシェルスクリプトを必要としません。プログラムに付属しているスクリプトを使うよりも、スクラッチからシェルスクリプトを書くことを推奨します。(Cygwin など) カスタム環境をテストするコードや、{{Ic\|JAVA_HOME}} が設定されているかどうか確認するコードは削除してください (Arch では {{ic\|JAVA_HOME}} を[[Java#インストール\|使用せず]]、{{ic\|archlinux-java}} を使って {{ic\|/usr/bin/java}} シンボリックリンクを設定します)。
	* If the program is meant to be run by the user, write a custom shell script that runs the main jar file. This script should be placed in {{Ic\|/usr/bin}}. Libraries generally do not require shell scripts. Write the shell script from scratch, rather than using one that is bundled with the program. Remove code that tests for custom environments (like Cygwin), and code that tries to determine if {{Ic\|JAVA_HOME}} has been set (Arch [[Java#JVM の切り替え\|does not use]] {{ic\|JAVA_HOME}}, it uses {{ic\|archlinux-java}} to set the {{ic\|/usr/bin/java}} symlink).

			:jar ファイルのスクリプトは以下のようになります:
	such script should look like this for jar files:
	#!/bin/sh		:{{Bc\|<nowiki>#!/bin/sh
	exec /usr/bin/java -jar '/usr/share/java/PROGRAMNAME/PROGRAMNAME.jar' "$@"		exec /usr/bin/java -jar '/usr/share/java/PROGRAMNAME/PROGRAMNAME.jar' "$@"</nowiki>}}

			:クラスファイルのスクリプトは以下のようになります:
	and like this for single class files:
	#!/bin/sh		:{{Bc\|<nowiki>#!/bin/sh
	exec /usr/bin/java '/usr/share/java/PROGRAMNAME/PROGRAMCLASSNAME' "$@"		exec /usr/bin/java '/usr/share/java/PROGRAMNAME/PROGRAMCLASSNAME' "$@"</nowiki>}}

	* Set the {{Ic\|CLASSPATH}} using the {{Ic\|-cp}} option to the Java interpreter unless there is an explicit reason not to (ie: the {{Ic\|CLASSPATH}} is used as a plugin mechanism). The {{Ic\|CLASSPATH}} should include all jar files in the {{Ic\|/usr/share/java/myprogram}} direcory, as well as jar files that are from dependency libraries that have been refactored to other directories. You can use something like the following code:		* Set the {{Ic\|CLASSPATH}} using the {{Ic\|-cp}} option to the Java interpreter unless there is an explicit reason not to (ie: the {{Ic\|CLASSPATH}} is used as a plugin mechanism). The {{Ic\|CLASSPATH}} should include all jar files in the {{Ic\|/usr/share/java/myprogram}} direcory, as well as jar files that are from dependency libraries that have been refactored to other directories. You can use something like the following code:
	for name in /usr/share/java/myprogram/*.jar ; do		:{{Bc\|<nowiki>for name in /usr/share/java/myprogram/*.jar ; do
	CP=$CP:$name		CP=$CP:$name
	done		done
	CP=$CP:/usr/share/java/dep1/dep1.jar		CP=$CP:/usr/share/java/dep1/dep1.jar
	java -cp $CP myprogram.java.MainClass		java -cp $CP myprogram.java.MainClass</nowiki>}}

	* Make sure the shell script is executable!		* Make sure the shell script is executable!
49行目:		49行目:
	* Other files distributed with the package should be stored in a directory named after the package under {{Ic\|/usr/share}}. You may need to set the location of this directory in a variable like {{Ic\|MYPROJECT_HOME}} inside the shell script. This guideline assumes that the program expects all files to be in the same directory (as is standard with Java packages). If it seems more natural to put a configuration file elsewhere (for example, logs in {{Ic\|/var/log}}), then feel free to do so.		* Other files distributed with the package should be stored in a directory named after the package under {{Ic\|/usr/share}}. You may need to set the location of this directory in a variable like {{Ic\|MYPROJECT_HOME}} inside the shell script. This guideline assumes that the program expects all files to be in the same directory (as is standard with Java packages). If it seems more natural to put a configuration file elsewhere (for example, logs in {{Ic\|/var/log}}), then feel free to do so.

			: 環境によっては {{Ic\|/usr}} は読み取り専用でマウントされる場合もあるので注意してください。アプリケーションによる書き込みが必要なファイルが共有ディレクトリに存在する場合、{{Ic\|/etc}} や {{Ic\|/var}}、あるいはユーザーのホームディレクトリに再配置できないか確認してください。
	Bear in mind that {{Ic\|/usr}} may be mounted as read-only on some systems. If there are files in the shared directory that need to be written by the application, they may have to be relocated to {{Ic\|/etc}}, {{Ic\|/var}}, or the user's home directory.

	* As is standard with Arch Linux packages, if the above standards cannot be adhered to without a serious amount of work, the package should be installed in its preferred manner, with the resulting directory located in {{Ic\|/opt}}. This is useful for programs that bundle JREs or include customized versions of dependencies, or do other strange or painful tasks.		* As is standard with Arch Linux packages, if the above standards cannot be adhered to without a serious amount of work, the package should be installed in its preferred manner, with the resulting directory located in {{Ic\|/opt}}. This is useful for programs that bundle JREs or include customized versions of dependencies, or do other strange or painful tasks.

	===複数の API 実装===		===複数の API 実装===
			一般的に使われる API 実装 (JDBC ドライバーなど) を配布するパッケージは {{Ic\|/usr/share/java/''apiname''}} にライブラリを配置してください。アプリケーションからユーザーが実装を選択できるようにするためです。{{Ic\|/usr/share/java/''apiname''}} を使用できるのはライブラリしか含まないパッケージだけです。アプリケーションの一部として実装が含まれる場合、通常のパッケージツリーと同じ場所に配置してください。
	If your package distributes commonly used API implementation(like jdbc driver) you should place the library under {{Ic\|/usr/share/java/''apiname''}}. So that applications that allow user to select from various implementations
	will know where to look for them. Use this location only for raw library packages. If such a implementation is part of distribution of application, '''do not''' place this jar file under common location but use ordinary package structure.

	===ディレクトリ構造の例===		===ディレクトリ構造の例===
			以下は {{Ic\|foo}} という仮のプログラムのディレクトリ構造の例です。{{Ic\|foo}} は一般的な名前なので、パッケージの名前は {{Ic\|java-foo}} としていますが、以下のディレクトリではその名前は使っていません:
	To clarify, here is an example directory structure for a hypothetical program called {{Ic\|foo}}. Since {{Ic\|foo}} is a common name, the package is named {{Ic\|java-foo}}, but notice this is not reflected in the directory structure:

	* {{Ic\|/usr/share/java/foo/}}		* {{Ic\|/usr/share/java/foo/}}
	* {{Ic\|/usr/share/java/foo/foo.jar}}		* {{Ic\|/usr/share/java/foo/foo.jar}}
	* {{Ic\|/usr/share/java/foo/bar.jar}} (~~included dependency of~~ {{Ic\|java-foo}})		* {{Ic\|/usr/share/java/foo/bar.jar}} ({{Ic\|java-foo}} の依存ライブラリ)
	* {{Ic\|/usr/share/foo/}}		* {{Ic\|/usr/share/foo/}}
	* {{Ic\|/usr/share/foo/.}} (~~some general files required by~~ {{Ic\|java-foo}})		* {{Ic\|/usr/share/foo/.}} ({{Ic\|java-foo}} が必要とする汎用のファイル)
	* {{Ic\|/usr/bin/foo}} (~~executable shell script~~)		* {{Ic\|/usr/bin/foo}} (実行可能なシェルスクリプト)

	===依存パッケージ===		===依存パッケージ===

Kusakata: 文字列「[[zh-CN:」を「[[zh-hans:」に置換

2017-01-28T15:36:10Z

文字列「[[zh-CN:」を「[[zh-hans:」に置換

← 古い版		2017年1月29日 (日) 00:36時点における版
2行目:		2行目:
	[[en:Java package guidelines]]		[[en:Java package guidelines]]
	[[it:Java package guidelines]]		[[it:Java package guidelines]]
	[[zh-CN:Java package guidelines]]		[[zh-hans:Java package guidelines]]
	{{Package Guidelines}}		{{Package Guidelines}}

Kusakata: 同期

2016-09-24T12:54:11Z

同期

← 古い版		2016年9月24日 (土) 21:54時点における版
18行目:		18行目:

	==パッケージング==		==パッケージング==
			Arch で Java アプリケーションをパッケージ化するのは骨の折れる作業です。しかしながら、上手くパッケージ化することでファイルシステムをきれいにして同梱する依存ライブラリを減らせます (Java ライブラリがパッケージとして作り直されることで、パッケージ化も楽になります)。Arch Linux の Java パッケージを作成するときは以下のガイドラインに従ってください:
	Packaging Java applications in Arch is going to take quite a bit more work for packagers than it currently does. The effort will be worth it, however, resulting in a cleaner filesystem and fewer bundled dependencies (as more and more Java libraries are refactored into their own packages, packaging will become easier). The following guidelines should be followed in creating an Arch Linux Java package:

			* Java ライブラリの名前が普遍的なものである場合、パッケージの名前に {{Ic\|java-}} を付けて他のライブラリと区別ができるようにしてください。ユニークな名前が付いているパッケージ (JUnit など) やエンドユーザープログラム (Eclipse など)、他のプリフィックスが存在するライブラリ (jakarta-commons-collections や apache-ant など) では必須ではありません。
	* If a Java library has a generic name, the package name should be prepended with the title {{Ic\|java-}} to help distinguish it from other libraries. This is not necessary with uniquely named packages (like JUnit), end-user programs (like Eclipse), or libraries that can be uniquely described with another prefix (like jakarta-commons-collections or apache-ant).

			* Java アプリケーションをソースからコンパイルする必要はありません。gcc で作成されたバイナリと同じように、コンパイルによって得られる最適化は僅かです。ソースからビルドする簡単な方法がソースパッケージに用意されている場合はそれを使ってかまいませんが、バイナリリリースの jar ファイルやインストーラーを取得するほうが簡単な場合はそれで結構です。
	* You do not need to compile Java applications from source. Very little optimization goes into the compile process, as with gcc created binaries. If the source package provides an easy way to build from source go ahead and use it, but if its easier to just grab a binary release of a jar file or an installer you may use that as well.

	* Place all jar files (and no other files) distributed with the program in a {{Ic\|/usr/share/java/myprogram}} directory. This includes all dependency jar files distributed with the application. However, effort should be made to place common or large dependency libraries into their own packages. This can only happen if the program does not depend on a specific version of a dependency library.		* Place all jar files (and no other files) distributed with the program in a {{Ic\|/usr/share/java/myprogram}} directory. This includes all dependency jar files distributed with the application. However, effort should be made to place common or large dependency libraries into their own packages. This can only happen if the program does not depend on a specific version of a dependency library.
28行目:		28行目:
	This rule makes it possible to iteratively refactor dependencies. That is, the package and all its dependencies can be placed into one directory at first. After this has been tested, major dependencies can be refactored out one at a time. Note that some applications include bundled dependencies inside the main jar file. That is, they unjar the bundled dependencies and include them in the main jar. Such dependencies are usually very small and there is little point in refactoring them.		This rule makes it possible to iteratively refactor dependencies. That is, the package and all its dependencies can be placed into one directory at first. After this has been tested, major dependencies can be refactored out one at a time. Note that some applications include bundled dependencies inside the main jar file. That is, they unjar the bundled dependencies and include them in the main jar. Such dependencies are usually very small and there is little point in refactoring them.

	* If the program is meant to be run by the user, write a custom shell script that runs the main jar file. This script should be placed in {{Ic\|/usr/bin}}. Libraries generally do not require shell scripts. Write the shell script from scratch, rather than using one that is bundled with the program. Remove code that tests for custom environments (like Cygwin), and code that tries to determine if {{Ic\|JAVA_HOME}} has been set (Arch [[Java#~~旧ワンタイム設定~~\|does not use]] {{ic\|JAVA_HOME}}, it uses {{ic\|archlinux-java}} to set the {{ic\|/usr/bin/java}} symlink).		* If the program is meant to be run by the user, write a custom shell script that runs the main jar file. This script should be placed in {{Ic\|/usr/bin}}. Libraries generally do not require shell scripts. Write the shell script from scratch, rather than using one that is bundled with the program. Remove code that tests for custom environments (like Cygwin), and code that tries to determine if {{Ic\|JAVA_HOME}} has been set (Arch [[Java#JVM の切り替え\|does not use]] {{ic\|JAVA_HOME}}, it uses {{ic\|archlinux-java}} to set the {{ic\|/usr/bin/java}} symlink).

	such script should look like this for jar files:		such script should look like this for jar files:
72行目:		72行目:
	大抵のパッケージでは、Java で書かれたソフトウェアを実行するのに {{Ic\|java-runtime}} が必要になります。{{Ic\|java-runtime}} は以下のパッケージに含まれている仮想パッケージです:		大抵のパッケージでは、Java で書かれたソフトウェアを実行するのに {{Ic\|java-runtime}} が必要になります。{{Ic\|java-runtime}} は以下のパッケージに含まれている仮想パッケージです:

			* {{Pkg\|jre8-openjdk}} (フリー)
	* {{Pkg\|jre7-openjdk}} (フリー)		* {{Pkg\|jre7-openjdk}} (フリー)
	* {{AUR\|java-gcj-compat}} (フリー)		* {{AUR\|java-gcj-compat}} (フリー)
78行目:		79行目:
	Java のソースコードをバイトコードにコンパイルする必要があるパッケージでは {{Ic\|java-environment}} (例: JDK) が必須になります。{{Ic\|java-environment}} は以下のパッケージに含まれている仮想パッケージです:		Java のソースコードをバイトコードにコンパイルする必要があるパッケージでは {{Ic\|java-environment}} (例: JDK) が必須になります。{{Ic\|java-environment}} は以下のパッケージに含まれている仮想パッケージです:

			* {{Pkg\|jdk8-openjdk}} (フリー)
	* {{Pkg\|jdk7-openjdk}} (フリー)		* {{Pkg\|jdk7-openjdk}} (フリー)
	* {{AUR\|jdk}} (ノンフリー)		* {{AUR\|jdk}} (ノンフリー)

2016年1月2日 (土) 03:16にKusakataによる

2016-01-02T03:16:46Z

← 古い版		2016年1月2日 (土) 12:16時点における版
1行目:		1行目:
	[[Category:パッケージ開発]]		[[Category:パッケージ開発]]
	[[en:Java package guidelines]]		[[en:Java package guidelines]]
	[[it:Java ~~Package~~ ~~Guidelines~~]]		[[it:Java package guidelines]]
	[[zh-CN:Java ~~Package~~ ~~Guidelines~~]]		[[zh-CN:Java package guidelines]]
	{{Package Guidelines}}		{{Package Guidelines}}

			この文章では Arch Linux における [[Java]] プログラムのパッケージングについて提唱される標準を定義しています。Java プログラムは依存関係を重ねないようにパッケージ化するのが大変難しいことで有名です。この文章ではそれをなんとか改善する方法を説明します。Java アプリケーションを扱うときは様々な場面に合わせて以下のガイドラインを臨機応変に読み替えてください。
	This document defines a proposed standard for packaging [[Java]] programs under Arch Linux. Java programs are notoriously difficult to package cleanly without overlapping dependencies. This document describes a way to remedy this situation. These guidelines are flexible in order to cover the many different scenarios that arise when dealing with Java applications.

	==イントロダクション==		==イントロダクション==
			Java パッケージの処理方法について Arch Linux のパッケージ作成者が合意を取ることは不可能です。公式・非公式リポジトリや [[AUR]] に存在する [[PKGBUILD]] では様々な手段が使われています。{{Ic\|/opt}} に全てのファイルを配置して、{{Ic\|/usr/bin}} にシェルスクリプトを置いたり {{Ic\|/etc/profile}} にプロファイルを保存する方法もあれば、{{Ic\|/usr/share}} のディレクトリにファイルを配置して {{Ic\|/usr/bin}} にスクリプトを置いているのもあります。システムの {{Ic\|CLASSPATH}} や {{Ic\|PATH}} には多くの不必要なファイルが追加されています。
	Arch Linux packagers cannot seem to agree on how to handle Java packages. Various methods are used in [[PKGBUILD]]s across the official and unofficial repositories and in the [[AUR]]. These solutions include placing the whole mess in {{Ic\|/opt}} with shell scripts in {{Ic\|/usr/bin}} or profiles placed in {{Ic\|/etc/profile}}. Others are placed in directories in {{Ic\|/usr/share}} with scripts placed in {{Ic\|/usr/bin}}. Many add unnecessary files to the system {{Ic\|CLASSPATH}} and {{Ic\|PATH}}.

	==典型的な Java アプリケーションの構造==		==典型的な Java アプリケーションの構造==
			ほとんどの Java のデスクトップアプリケーションは同じような構造をしています。これらのアプリケーションはシステムに依存しない (ただしパッケージに依存する) インストーラーによってインストールされます。大抵は全てを単一のディレクトリにインストールして {{Ic\|bin}}, {{Ic\|lib}}, {{Ic\|jar}}, {{Ic\|conf}} などのサブディレクトリが作られます。通常、メインの jar ファイルが存在していて、メインの実行クラスが記述されています。また、Java インタプリタを直接実行しなくてもいいように、メインクラスを実行するためのシェルスクリプトも付属しているのが普通です。シェルスクリプトは様々なディストリビューションで共通して用いられ、別の環境 (例: Cygwin) 用の特殊なケースもカバーするようになっている場合が多く、非常に複雑になっています。
	Most Desktop Java applications have a similar structure. They are installed from a system-independent (but package dependent!) installer. This usually installs everything in a single directory with subdirectories called {{Ic\|bin}}, {{Ic\|lib}}, {{Ic\|jar}}, {{Ic\|conf}}, etc. There is usually a main jar file containing the main executable classes. A shell script is usually provided to run the main class so users do not have to invoke the Java interpreter directly. This shell script is usually quite complex, as it is generic across distributions and often includes special cases for different systems (e.g., Cygwin).

			{{Ic\|lib}} ディレクトリには jar ファイルがバンドルされているのが通例で、Java アプリケーションの依存関係を満たすようになっています。(全ての依存パッケージが含まれていることは) プログラムをインストールしたいユーザーにとっては楽ですが、パッケージの開発者にとっては悪夢です。同一の依存パッケージを複数のパッケージがバンドルしていることは無駄に他なりません。Java のデスクトップアプリケーションやライブラリの数が少なかった昔はそこまで大きな問題ではありませんでしたが、Java アプリケーションとライブラリの数が増えるにつれて避けがたい問題になっています。時代は変わったのです。
	The {{Ic\|lib}} directory often contains bundled jar files that satisfy dependencies of the Java application. This makes it simple for a user to install the program (all dependencies included), but is a package developer's nightmare. It is a waste of space when several packages bundle the same dependency. This was not a big issue in the past when there were fewer desktop Java applications and libraries, and those that existed tended to be very large anyway. Things are different now...

			プログラムを実行するのに必要な他のファイルはメインの jar ファイルと同じフォルダに保存されるか、サブディレクトリに保存されるのが普通です。Java プログラムはどこからクラスがロードされたか関知しないので、jar ファイルがあるディレクトリ内から実行しなくてはなりません (シェルスクリプトでディレクトリに {{Ic\|cd}} する必要がある)。あるいは、ディレクトリの場所を示す環境変数を設定します。
	Other files necessary to run the program are usually stored in the same folder as the main jar file, or a subdirectory thereof. Since Java programs do not know where their classes were loaded from, they usually need to be run from within this directory (i.e. the shell script should {{Ic\|cd}} into the directory), or an environment variable is set to indicate the directory's location.

	==パッケージング==		==パッケージング==
68行目:		68行目:

	===依存パッケージ===		===依存パッケージ===
	Java ~~packages might specify~~ {{Ic\|java-runtime}} or {{Ic\|java-environment}} ~~as dependency, based on what they need.~~		Java パッケージには、必要に応じて、{{Ic\|java-runtime}} あるいは {{Ic\|java-environment}} を依存パッケージとして指定します。

			大抵のパッケージでは、Java で書かれたソフトウェアを実行するのに {{Ic\|java-runtime}} が必要になります。{{Ic\|java-runtime}} は以下のパッケージに含まれている仮想パッケージです:
	For most packages, {{Ic\|java-runtime}} is what is needed to simply run software written in Java. {{Ic\|java-runtime}} is a virtual dependency provided by:

	* {{Pkg\|jre7-openjdk}} (~~free~~)		* {{Pkg\|jre7-openjdk}} (フリー)
	* {{AUR\|java-gcj-compat}} (~~free~~)		* {{AUR\|java-gcj-compat}} (フリー)
	* {{AUR\|jre}} (~~non-free~~)		* {{AUR\|jre}} (ノンフリー)

			Java のソースコードをバイトコードにコンパイルする必要があるパッケージでは {{Ic\|java-environment}} (例: JDK) が必須になります。{{Ic\|java-environment}} は以下のパッケージに含まれている仮想パッケージです:
	{{Ic\|java-environment}} (e.g. JDK) is needed by packages that will need to compile Java source code into bytecode. {{Ic\|java-environment}} is a virtual dependency provided by:

	* {{Pkg\|jdk7-openjdk}} (~~free~~)		* {{Pkg\|jdk7-openjdk}} (フリー)
	* {{AUR\|jdk}} (~~non-free~~)		* {{AUR\|jdk}} (ノンフリー)

Kusakata: ページの作成:「Category:パッケージ開発 en:Java package guidelines it:Java Package Guidelines zh-CN:Java Package Guidelines {{Package Guidelines}} This document d...」

2015-08-10T06:55:41Z

ページの作成:「Category:パッケージ開発 en:Java package guidelines it:Java Package Guidelines zh-CN:Java Package Guidelines {{Package Guidelines}} This document d...」

新規ページ

[[Category:パッケージ開発]]
[[en:Java package guidelines]]
[[it:Java Package Guidelines]]
[[zh-CN:Java Package Guidelines]]
{{Package Guidelines}}

This document defines a proposed standard for packaging [[Java]] programs under Arch Linux. Java programs are notoriously difficult to package cleanly without overlapping dependencies. This document describes a way to remedy this situation. These guidelines are flexible in order to cover the many different scenarios that arise when dealing with Java applications.

==イントロダクション==
Arch Linux packagers cannot seem to agree on how to handle Java packages. Various methods are used in [[PKGBUILD]]s across the official and unofficial repositories and in the [[AUR]]. These solutions include placing the whole mess in {{Ic|/opt}} with shell scripts in {{Ic|/usr/bin}} or profiles placed in {{Ic|/etc/profile}}. Others are placed in directories in {{Ic|/usr/share}} with scripts placed in {{Ic|/usr/bin}}. Many add unnecessary files to the system {{Ic|CLASSPATH}} and {{Ic|PATH}}.

==典型的な Java アプリケーションの構造==
Most Desktop Java applications have a similar structure. They are installed from a system-independent (but package dependent!) installer. This usually installs everything in a single directory with subdirectories called {{Ic|bin}}, {{Ic|lib}}, {{Ic|jar}}, {{Ic|conf}}, etc. There is usually a main jar file containing the main executable classes. A shell script is usually provided to run the main class so users do not have to invoke the Java interpreter directly. This shell script is usually quite complex, as it is generic across distributions and often includes special cases for different systems (e.g., Cygwin).

The {{Ic|lib}} directory often contains bundled jar files that satisfy dependencies of the Java application. This makes it simple for a user to install the program (all dependencies included), but is a package developer's nightmare. It is a waste of space when several packages bundle the same dependency. This was not a big issue in the past when there were fewer desktop Java applications and libraries, and those that existed tended to be very large anyway. Things are different now...

Other files necessary to run the program are usually stored in the same folder as the main jar file, or a subdirectory thereof. Since Java programs do not know where their classes were loaded from, they usually need to be run from within this directory (i.e. the shell script should {{Ic|cd}} into the directory), or an environment variable is set to indicate the directory's location.

==パッケージング==
Packaging Java applications in Arch is going to take quite a bit more work for packagers than it currently does. The effort will be worth it, however, resulting in a cleaner filesystem and fewer bundled dependencies (as more and more Java libraries are refactored into their own packages, packaging will become easier). The following guidelines should be followed in creating an Arch Linux Java package:

* If a Java library has a generic name, the package name should be prepended with the title {{Ic|java-}} to help distinguish it from other libraries. This is not necessary with uniquely named packages (like JUnit), end-user programs (like Eclipse), or libraries that can be uniquely described with another prefix (like jakarta-commons-collections or apache-ant).

* You do not need to compile Java applications from source. Very little optimization goes into the compile process, as with gcc created binaries. If the source package provides an easy way to build from source go ahead and use it, but if its easier to just grab a binary release of a jar file or an installer you may use that as well.

* Place all jar files (and no other files) distributed with the program in a {{Ic|/usr/share/java/myprogram}} directory. This includes all dependency jar files distributed with the application. However, effort should be made to place common or large dependency libraries into their own packages. This can only happen if the program does not depend on a specific version of a dependency library.

This rule makes it possible to iteratively refactor dependencies. That is, the package and all its dependencies can be placed into one directory at first. After this has been tested, major dependencies can be refactored out one at a time. Note that some applications include bundled dependencies inside the main jar file. That is, they unjar the bundled dependencies and include them in the main jar. Such dependencies are usually very small and there is little point in refactoring them.

* If the program is meant to be run by the user, write a custom shell script that runs the main jar file. This script should be placed in {{Ic|/usr/bin}}. Libraries generally do not require shell scripts. Write the shell script from scratch, rather than using one that is bundled with the program. Remove code that tests for custom environments (like Cygwin), and code that tries to determine if {{Ic|JAVA_HOME}} has been set (Arch [[Java#旧ワンタイム設定|does not use]] {{ic|JAVA_HOME}}, it uses {{ic|archlinux-java}} to set the {{ic|/usr/bin/java}} symlink).

such script should look like this for jar files:
#!/bin/sh
exec /usr/bin/java -jar '/usr/share/java/PROGRAMNAME/PROGRAMNAME.jar' "$@"

and like this for single class files:
#!/bin/sh
exec /usr/bin/java '/usr/share/java/PROGRAMNAME/PROGRAMCLASSNAME' "$@"

* Set the {{Ic|CLASSPATH}} using the {{Ic|-cp}} option to the Java interpreter unless there is an explicit reason not to (ie: the {{Ic|CLASSPATH}} is used as a plugin mechanism). The {{Ic|CLASSPATH}} should include all jar files in the {{Ic|/usr/share/java/myprogram}} direcory, as well as jar files that are from dependency libraries that have been refactored to other directories. You can use something like the following code:
for name in /usr/share/java/myprogram/*.jar ; do
CP=$CP:$name
done
CP=$CP:/usr/share/java/dep1/dep1.jar
java -cp $CP myprogram.java.MainClass

* Make sure the shell script is executable!

* Other files distributed with the package should be stored in a directory named after the package under {{Ic|/usr/share}}. You may need to set the location of this directory in a variable like {{Ic|MYPROJECT_HOME}} inside the shell script. This guideline assumes that the program expects all files to be in the same directory (as is standard with Java packages). If it seems more natural to put a configuration file elsewhere (for example, logs in {{Ic|/var/log}}), then feel free to do so.

Bear in mind that {{Ic|/usr}} may be mounted as read-only on some systems. If there are files in the shared directory that need to be written by the application, they may have to be relocated to {{Ic|/etc}}, {{Ic|/var}}, or the user's home directory.

* As is standard with Arch Linux packages, if the above standards cannot be adhered to without a serious amount of work, the package should be installed in its preferred manner, with the resulting directory located in {{Ic|/opt}}. This is useful for programs that bundle JREs or include customized versions of dependencies, or do other strange or painful tasks.

===複数の API 実装===
If your package distributes commonly used API implementation(like jdbc driver) you should place the library under {{Ic|/usr/share/java/''apiname''}}. So that applications that allow user to select from various implementations
will know where to look for them. Use this location only for raw library packages. If such a implementation is part of distribution of application, '''do not''' place this jar file under common location but use ordinary package structure.

===ディレクトリ構造の例===
To clarify, here is an example directory structure for a hypothetical program called {{Ic|foo}}. Since {{Ic|foo}} is a common name, the package is named {{Ic|java-foo}}, but notice this is not reflected in the directory structure:

* {{Ic|/usr/share/java/foo/}}
* {{Ic|/usr/share/java/foo/foo.jar}}
* {{Ic|/usr/share/java/foo/bar.jar}} (included dependency of {{Ic|java-foo}})
* {{Ic|/usr/share/foo/}}
* {{Ic|/usr/share/foo/*.*}} (some general files required by {{Ic|java-foo}})
* {{Ic|/usr/bin/foo}} (executable shell script)

===依存パッケージ===
Java packages might specify {{Ic|java-runtime}} or {{Ic|java-environment}} as dependency, based on what they need.

For most packages, {{Ic|java-runtime}} is what is needed to simply run software written in Java. {{Ic|java-runtime}} is a virtual dependency provided by:

* {{Pkg|jre7-openjdk}} (free)
* {{AUR|java-gcj-compat}} (free)
* {{AUR|jre}} (non-free)

{{Ic|java-environment}} (e.g. JDK) is needed by packages that will need to compile Java source code into bytecode. {{Ic|java-environment}} is a virtual dependency provided by:

* {{Pkg|jdk7-openjdk}} (free)
* {{AUR|jdk}} (non-free)