[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: java-config (was Re: Java policy: finding the base directory of the default JRE/JDK)



Joerg Wendland wrote:

Barry Hawkins, on 2004-11-17, 09:29, you wrote:
That's what I have been doing, I just don't know if that's how we want
the Eclipse 3 package to work.  Is that what other Java applications
that need JAVA_HOME are doing?  It seems a bit of a kludge, but that
could be my inexperience with Debian packaging showing..

What about having sort of /usr/bin/java-config that returns the path to
JAVA_HOME of the currently used JDK?  So maintainers (of eclipse,
tomcat, jboss etc.) could simply add a line like

 JAVA_HOME=`/usr/bin/java-config --home`

to their scripts and be done.  Additionally there could be a tool, maybe
named update-java-config, that allows for easy switching between
installed JDKs and accounts for all update-alternatives and telling
java-config the correct location of JAVA_HOME. java-config could be easily extended to support using JDKs that are currently not marked as
being the default one (and using non-free ones with additional features
like rmid etc.).  This could look like:

 JAVA_HOME=`/usr/bin/java-config --flavor=jdk1.4-sun --home`
 JAVA=`/usr/bin/java-config --flavor=jdk1.4-sun --bin=java`
 RMID=`/usr/bin/java-config --flavor=jdk1.4-sun --bin=rmid`

 $RMID &
 $JAVA my.tool.to.be.Run
We already have such a tool for Gentoo, written in Python. This is
what it can do currently:

Usage: java-config [ OPTIONS ]
Options:
<< -h arg1[,arg2,...] --help=arg1[,arg2,...] >>
List all command line options with --help , for command specific long help
   messages use --help=command (ex. --help=javac)
<< -J --java >>
   Print the location of the java executable
<< -c --javac >>
   Print the location of the java byte compiler
<< -j --jar >>
   Print the location of the jar executable
<< -O --jdk-home >>
   Print the location of the current jdk home
<< -o --jre-home >>
   Print the location of the current jre home
<< -f --show-active-vm >>
   Show the active virtual machine
<< -v --java-version >>
   Print the version information for the in-use jvm
<< -p arg1[,arg2,...] --classpath=arg1[,arg2,...] >>
   Print entries in the enviroment or package classpath.
<< -g argument --get-env=argument >>
   Print an environment variable from the currently selected VM
<< -e arg1[,arg2,...] --exec=arg1[,arg2,...] >>
   Execute something that should be somewhere in the JAVA_HOME
<< -l --list-available-packages >>
   List all available packages
<< -L --list-available-vms >>
   List all available virtual machines
<< -P arg1[,arg2,...] --print=arg1[,arg2,...] >>
   Print the environment information for a specified VM
<< -S argument --set-system-vm=argument >>
   Set the VM for the entire system
<< -s argument --set-user-vm=argument >>
   Set the VM for a user
<< -A arg1[,arg2,...] --set-system-classpath=arg1[,arg2,...] >>
   Set the system classpath
<< -a arg1[,arg2,...] --set-user-classpath=arg1[,arg2,...] >>
   Set the user classpath
<< -B arg1[,arg2,...] --add-system-classpath=arg1[,arg2,...] >>
   Append to the system classpath
<< -b arg1[,arg2,...] --add-user-classpath=arg1[,arg2,...] >>
   Append to the user classpath
<< -X --clean-system-classpath >>
   Clean the classpath of all packages
<< -x --clean-user-classpath >>
   Clean the user classpath of all packages
<< -n --nocolor >>
   Turn off all colors.
<< -i arg1[,arg2,...] --library=arg1[,arg2,...] >>
   Print entries in the package library.

I don't know there is a Debian policy stating that such tools must be written in Perl and/or Bash on Debian, but if not, I think we may be well-served to fix java-config into working similarly across Gentoo and Debian (perhaps also Fedora?), so that users don't need to learn a new java-config every time they encounter a new Linux distro.

After all, cross-platformity works for pkg-config, which solves a much more difficult problem.

I'd be willing to spend time porting java-config to Debian if you guys are interested.

-- Karl T

PS. Also, suggestion for changes/improvements to the current java-config is more than welcome:)



Reply to: