Re: JAVA_HOME policy
On Thu, 2003-01-02 at 18:14, Andrew Pimlott wrote:
> Oooh--I'll answer this!
>
> On Thu, Jan 02, 2003 at 05:03:32PM -0500, Joe Phillips wrote:
> > I've seen package after package (mine included) depend on a
> > JAVA_HOME environment variable set somewhere, in some script.
> > Most packages seem to use a config file or init-script to define a
> > local JAVA_HOME. Source packages often have JAVA_HOME coded into
> > debian/rules.
>
> 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. Since
JAVA_HOME is so common, I hope mention of it would be made in the java
policy documentation.
> > I'm wondering if there's a better way to handle JAVA_HOME.
>
> 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
#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.
After thinking this through, it seems to me that what we need, in order
to solve #2 is to make tools.jar available in a standard place. I
propose we add a clause to the "Java Compilers" section (2.2) of Debian
Java Policy, stating that if a tools.jar is provided by the package, the
package should provide a tools.jar alternative. Using existing
terminology, the added line would read...
They should use /etc/alternatives for the name 'tools.jar' if
they are compatible with Sun's JDK tools.jar.
we may want to add a virtual package related to tools.jar as well. I'm
not sure how everyone feels about that.
Any more comments?
-joe
--
Innovation Software Group, LLC - http://www.innovationsw.com/
Business Automation Specialists
UNIX, Linux and Java Training
Reply to: