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.