Chapter 2. Policy

Virtual packages are created: java1-runtime, java2-runtime, java5-runtime, java5-runtime-headless, java6-runtime, java6-runtime-headless, java7-runtime, java7-runtime-headless, java8-runtime and java8-runtime-headless.

Packages written in Java are separated in two categories: programs and libraries. Programs are intended to be run by end-users. Libraries are intended to help programs to run and to be used by developers.

Both must be shipped as Java bytecode (*.class files, packaged in a *.jar archive) and with an "Architecture: all". There are rare exceptions to this such as Eclipse SWT. Exceptions to this rule can only be granted by the Java Team. Requests must be sent to .

The Java bytecode may additionally be shipped as machine code, as produced for example by the GNU Compiler for Java, in a separate architecture-specific package.

Programs and libraries should enable unit tests, if these are present. The build may ignore test failures.

2.1. Virtual machines

Java virtual machines must depend on java-common. They can also provide the runtime environment that the package supports (java1-runtime, java2-runtime, java8-runtime, java8-runtime-headless, etc). If it does not provide the files itself it must depend on the needed runtime environment.

They should use /etc/alternatives for the name 'java' if they are command-line compatible with the Oracle's java program.

They should have a CLASSPATH predefined which include the needed runtime environment.

If a given source (like the JDK does) brings both a compiler and a virtual machine, you may name the compiler package xxxx-dev.

Some Java classes implement their routines using a "native" language (such as C). This native code is compiled and stored in dynamic libraries (such as JNI modules) that are loaded at runtime. If a virtual machine supports native code, it must include the directory /usr/lib/jni in its search path for these dynamic libraries.