Virtual packages are created: java1-runtime and java2-runtime.
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 <debian-java@lists.debian.org>.
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.
Java virtual machines must depend on java-common. They can also provide the runtime environment that the package contains (java1-runtime and/or java2-runtime). 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.