On Fri, Jan 10, 2003 at 07:16:22PM -0500, Joe Phillips wrote: > On Thu, 2003-01-02 at 18:14, Andrew Pimlott wrote: > > Any package that depends on JAVA_HOME should be taken out and shot. > > Or, more politely, when it is packaged for Debian, those portions > > should be excised. > > Is this the concensus? You have been my only response so far.
I'm only here because I use Debian and sometimes have to program in Java. Either the real developers agree or are asleep. :-) > > Figure out what these packages really "need" JAVA_HOME for, and > > figure out how we can provide that in a general way, that can be > > supported by all java implementations (with emphasis on the free > > ones). > > Upon mulling this for a little while, I can think of two main reasons > that programs use JAVA_HOME... > > 1- to find the location of the 'java' command > 2- to find the location of the tools.jar file Well, that's great news. If we only have to solve two problems, it should be easy! Someone responded to me privately, and tools.jar was the only real issue he knew of, too. > #1 is really unnecessary. I can definitely understand changing startup > scripts and such to use /usr/bin/java or just 'java', allowing PATH and > alternatives to take care of the rest. Problem solved. > > #2 is a bit trickier. tools.jar is needed in some cases, most notably > servlet/jsp containers need it in order to compile JSP at runtime. My > JBOSS packages fall into this category. tools.jar is installed > somewhere under JAVA_HOME, JBOSS needs tools.jar and so needs JAVA_HOME. My understanding of tools.jar is that it is private, unsupported helper code for Sun's implementation. Nobody else should use it--though Sun probably doesn't mind, because it locks people into their implementation! But of course people are using it. Since it is non-standard, I assume that for most programs it is optional. (Does anyone know any cases in which it is not optional? If so, are there efforts to reimplement these libraries? Or change the programs not to rely on tools.jar?) So in Debian, we ought to have a way for programs to decide whether to use tools.jar, and, if so, to find it. In the case of the compiler API, presumably (hopefully) JBoss can call a command-line compiler if tools.jar is not found. In Debian, we probably want JBoss to use a command-line compiler by default, even if Sun's tools.jar is installed, since tools.jar is not free software and some of the command-line compilers are. Managing tools.jar with alternatives solves the problem of finding it (assuming that its API is sufficiently stable across JDK's--is it?). But it doesn't solve the problem of whether to use tools.jar in the first place. One slightly weird solution would be to check whether the javac alternative points to a Sun javac, and if so, use its tools.jar. We could put a program in java-common called javac-to-tools.jar that takes a path to a Java compiler, and returns the path to the corresponding tools.jar, or an empty string if the command line should be used instead. Or maybe this is overkill, and we should just make tools.jar an alternative and be done with it. On the premise that people who install a non-free JDK want to use it; or if they don't, they can modify the JBoss configuration by hand to specify another compiler. Andrew
