2.4. Native Java Bytecode (gcj packages)

Java bytecode compiled into native code is referred to as gcj-code and packages containing gcj-code as gcj-packages.

gcj-packages has been added in order to improve performance of Java libraries and programs. This is particularly useful on architectures where the JVM does not have a JIT. However, this performance comes at the cost of size, extra compilation time and creates architecture dependent packages.

Packages must not ship gcj-code without the permission of the Java team (<debian-java@lists.debian.org>). Source packages that shipped gcj-packages as of March 22nd,2010, have been given this permission through the ratification of this policy.

A request for permission to add gcj should convince the Java Team that the performance boost of adding the gcj-packages out-weights the disadvantages.

Source packages compiling gcj-packages must Build-Depend on gcj-native-helper (formerly known as default-jdk-builddep). The gcj-code should only be shipped for a selected set of architectures.

The gcj-code must be installed in /usr/lib/gcj/ and shipped separately from the original jar file. The gcj-package must also install the classmap file generated by aot-compile in /usr/share/gcj/classmap.d/.

The gcj-package must call rebuild-gcj-db in the postinst and postrm script, if rebuild-gcj-db is present.

The gcj-package must depend on the package providing the jar file, it is a native compilation. The package containing the jar file must declare either a Suggests or a Recommends relationship on the gcj-package.