| Debian Java Packaging Project | ||
It is very important to get the same results in the binary packages independent of the build environment. This means that you should use one specific JDK version and an exactly defined CLASSPATH for building your package.
java, javac, ... with their full path (don't use /usr/bin/java!).
A lot of weird things may happen if you use /usr/bin/java or /usr/bin/javac since both are managed by update-alternatives. javac and java might even point to different JDK versions, so a class that gets compiled by /usr/bin/javac might not be able to run with /usr/bin/java, for example when assertions in JDK 1.4 are used.
Some packages enable or disable extra features depending on the JDK version they were built with, for example the PostgreSQL JDBC driver builds a JDBC 1.0 version on JDK 1.1, a JDBC 2.0 version on JDK 1.2/1.3 and an extended JDBC 2.0 version on JDK 1.4 or higher.
Another example is bug #197484: Refactoring did not work in Eclipse when it was built with JDK 1.4 and the problem went away when using JDK 1.3 - the only way to avoid getting a buggy package is to use one specific JDK in debian/rules.
/usr/bin/java* might even point to a locally installed JDK so additional (possibly non-free) package dependencies might be pulled in, for example when new APIs like JMS or JTA are available during build time. And you don't even know about them!
This situation is completely different from using /usr/bin/gcc or /usr/bin/g++ for C and C++ programms since they are not managed by update-alternatives. Admitted, they might point to gcc 2.95, gcc 3.2 or gcc 3.3 but they are provided by a single package and never point to a locally installed GCC version. And the library dependencies are resolved by dpkg-shlibdeps.
Last Modified: $Date: 2006-01-26 10:40:40 +0000 (Thu, 26 Jan 2006) $