Re: JAVA_HOME policy
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
Reply to: