On Sat, Apr 09, 2005 at 11:24:37AM -0500, Jerry Haltom wrote:
> Anybody interested in this at all?
Sorry, I was busy this week and I wanted to think about it a bit.
>
> On Sun, 2005-04-03 at 11:12 -0500, Jerry Haltom wrote:
> > We need a standard, nice, easy to extend way for binary wrappers
> > in /usr/bin and/or startup scripts to locate their VM. There are a few
> > requirements that I had:
> >
> > 1) Whatever we do should be GUI configurable. I want to write a "System
> > VM Selection" control panel of some sort allowing the user to choose
> > which VM is used system-wide and also program specific.
> >
> > 2) It would be nice if a user (or us, as maintainers) could set the
> > system up so that a certain VM is used by default for a certain program.
> > There is a very obvious use case for wanting to run something like
> > Eclipse on Sun's VM, yet everything else on GCJ (at least until we are
> > feature complete with Sun!)
> >
> > 3) It should be overridable per user. If only one user wants to run
> > Eclipse on Sun, he should be able to.
> >
> > So the obvious way to implement this is to write a shell script fragment
> > which queries a number of files and returns a valid path to a JAVA_HOME.
> > We then include this fragment at the top of existing wrappers, or such
> > as in the case of Ant, just replace the wrapper (the Ant wrapper sucks
> > really badly.)
> >
> > Here's my idea. A JVM selection file is just a file listing JAVA_HOME
> > paths in order of preference. We put the default system one here:
> >
> > /etc/jvm
> >
> > Additionally, we create a directory to hold per program files.
> >
> > /etc/jvm.d
> >
> > A file in here would be for example named 'ant'. I'd like to talk about
> > this naming convention for these files. I'm thinking we'd use the same
> > stuff as like, /usr/share/$prog, not the specific package name.
> >
> > The script would test for /etc/jvm.d/prog, test each JAVA_HOME listed
> > within, then, if it hasn't found a jvm yet, proceed with /etc/jvm.
> >
> > We could also have it check ~/.jvm.d and ~/.jvm in the same manor.
> >
> > Because I like doing things before I talk about them, I did this. This
> > file would be cleaned up, placed in java-common, perhaps
> > in /usr/share/java-common/jvm.sh, and jvm_find would be called in each
> > wrapper.
> >
> > #!/bin/bash
> >
> > function jvm_scan_file() {
> > file="$1"
> >
> > while read jvm; do
> > if [ -x "$jvm/bin/java" ]; then
> > echo $jvm
> > return
> > fi
> > done < <(cat "$file" | grep -v '#')
> > }
> >
> > function jvm_find() {
> > program_file="/etc/jvm.d/$1"
> > user_program_file="$HOME/.jvm.d/$1"
> >
> > if [ -r "$user_program_file" ]; then
> > jvm="$(jvm_scan_file "$user_program_file")"
> > fi
> >
> > if [ -r "$HOME/.jvm" ]; then
> > jvm="$(jvm_scan_file "$HOME/.jvm")"
> > fi
> >
> > if [ -r "$program_file" ]; then
> > jvm="$(jvm_scan_file "$program_file")"
> > fi
> >
> > if [ -z "$jvm" ]; then
> > jvm="$(jvm_scan_file /etc/jvm)"
> > fi
> >
> > echo "$jvm"
> > }
> >
> > Then a wrapper just sources it, JAVA_HOME=`jvm_find myname`, and goes
> > on.
Good work, Jerry.
I really like this idea. Its simple and allows big flexibility.
Including this in java-common package and updating our policy (it needs
an update anyway) should be a high priority. I vote that we just do it
if noone has against this proposal in the next 7 days. Then we can
depend on the specific version of java-common and use this very nice
feature. I really like to use it for gjdoc as kaffe is the only VM I
know it really works with yet (gcj-4.0 works too but is not in unstable
yet).
Michael
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
