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.
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.