Getting JAVA_HOME at runtime  
Author Message
Jean-Baptiste Quenot





PostPosted: 2006-4-12 2:02:00 Top

java-programmer, Getting JAVA_HOME at runtime Hello,

The Java ports infrastructure provides JAVA_HOME on build-time to
port's Makefile. But is it possible to get this variable from
/usr/local/bin/java at runtime?

How to change the Java version for a port at runtime in the rc
script? It is possible to set the preferred JDK in
/usr/local/etc/javavms but then JAVA_HOME still needs to be
set manually.

I would like to avoid hard-coding the JAVA_HOME at build time in
the rc scripts.

Any idea?
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
 
Herve Quiroz





PostPosted: 2006-4-12 6:24:00 Top

java-programmer >> Getting JAVA_HOME at runtime On Tue, Apr 11, 2006 at 08:01:46PM +0200, Jean-Baptiste Quenot wrote:
> The Java ports infrastructure provides JAVA_HOME on build-time to
> port's Makefile. But is it possible to get this variable from
> /usr/local/bin/java at runtime?
>
> How to change the Java version for a port at runtime in the rc
> script? It is possible to set the preferred JDK in
> /usr/local/etc/javavms but then JAVA_HOME still needs to be
> set manually.
>
> I would like to avoid hard-coding the JAVA_HOME at build time in
> the rc scripts.
>
> Any idea?

In /usr/local/bin/javavm, line 447:

export JAVA_HOME
tryJavaCommand "${JAVA_HOME}/bin/${IAM}" "${@}"

So indeed, JAVA_HOME is set accordingly to the JVM picked up by the
script.

That's how the launcher shell script works for devel/maven2 for example.

Herve
 
Jean-Baptiste Quenot





PostPosted: 2006-4-13 2:00:00 Top

java-programmer >> Getting JAVA_HOME at runtime * Herve Quiroz:

> In /usr/local/bin/javavm, line 447:
>
> export JAVA_HOME
> tryJavaCommand "${JAVA_HOME}/bin/${IAM}" "${@}"
>
> So indeed, JAVA_HOME is set accordingly to the JVM picked up by the
> script.
>
> That's how the launcher shell script works for devel/maven2 for example.

OK, but imagine that the target application has a shell script
that needs JAVA_HOME. There are plenty of programs that are based
on JAVA_HOME instead of the java binary.

How to get the preferred JAVA_HOME?
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
 
 
Herve Quiroz





PostPosted: 2006-4-15 8:41:00 Top

java-programmer >> Getting JAVA_HOME at runtime On Wed, Apr 12, 2006 at 08:00:28PM +0200, Jean-Baptiste Quenot wrote:
> > So indeed, JAVA_HOME is set accordingly to the JVM picked up by the
> > script.
> >
> > That's how the launcher shell script works for devel/maven2 for example.
>
> OK, but imagine that the target application has a shell script
> that needs JAVA_HOME. There are plenty of programs that are based
> on JAVA_HOME instead of the java binary.
>
> How to get the preferred JAVA_HOME?

ATM you can't. So far, each time I needed such feature I found a
workaround or ended up enforcing a JDK in the shell script.

Depending on the script you have in mind, such feature could indeed be
interesting to implement. The main problem I see here is that javavm
cannot tell which JVM is the good one until it manages to run one. So
the only way to be sure of our JAVA_HOME would be to run a Java class
that uses System.getEnv() to display JAVA_HOME to the standard output.
This would just double the startup time of the application. Anyway, if
this JAVA_HOME is important to determine, and when dealing with a
"server" application which is run once in a while (e.g. at boot), I can
imagine it could be worth it.

Herve
 
 
Jean-Baptiste Quenot





PostPosted: 2006-4-17 18:25:00 Top

java-programmer >> Getting JAVA_HOME at runtime * Herve Quiroz:

> ATM you can't. So far, each time I needed such feature I found a
> workaround or ended up enforcing a JDK in the shell script.

Actually I found a solution by analyzing what javavm is doing:

make -f /usr/ports/Mk/bsd.port.mk -V JAVA_HOME USE_JAVA=yes

And this will allow the sysadmin to set a version requirement, eg:

resin2_java_version=1.5+

Will be translated into:

JAVA_HOME=$(make -f /usr/ports/Mk/bsd.port.mk -V JAVA_HOME USE_JAVA=yes JAVA_VERSION="${resin2_java_version}")

However it slows down a little bit the rc script.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
 
 
Jean-Baptiste Quenot





PostPosted: 2006-4-18 16:49:00 Top

java-programmer >> Getting JAVA_HOME at runtime * Greg Lewis:

> Yes. It also potentially fails if the machine has installed the
> resin2 package but hasn't got the ports tree installed.

Right.

> Unfortunately I don't have a good solution to that at the
> moment. It almost seems like we want a flag or environment
> variable that tells javavmwrapper to dump what it found out
> rather than actually executing anything.

That would be interesting, but can you confirm that the JDK lookup
algorithm is implemented both in bsd.java.mk and in javavm? We
might want to unify both, for example bsd.java.mk should use the
wrapper.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
 
 
Jean-Baptiste Quenot





PostPosted: 2006-4-19 21:41:00 Top

java-programmer >> Getting JAVA_HOME at runtime
* Herve Quiroz:

> javavmwrapper, OTOH, uses the logic from bsd.java.mk (not
> reimplementing it) to pick a port that is *already* installed
> via the ports.

You're right, but if it can't read bsd.port.mk, javavm tries to
find the JDK itself from line 465 to line 573, that's why I say we
have two implementations of the lookup algorithm.

I'm attaching a patch to add documentation to javavm, and to allow
for a JAVAVM_DRY_RUN environment variable that makes javavm find
the best suitable JVM and print the corresponding value of
JAVA_HOME instead of executing it.

If you are interested, I can submit a PR.

For this to work correctly, we need javavm to stop upon failure.
Until now, when the java program cannot be exec-uted, javavm
issues a warning and goes on to the next JVM.

Best regards,
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/

 
 
Jean-Baptiste Quenot





PostPosted: 2006-4-19 21:49:00 Top

java-programmer >> Getting JAVA_HOME at runtime
This one will still be better.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/

 
 
Herve Quiroz





PostPosted: 2006-4-19 22:59:00 Top

java-programmer >> Getting JAVA_HOME at runtime Hi Jean-Baptiste,

On Wed, Apr 19, 2006 at 03:40:41PM +0200, Jean-Baptiste Quenot wrote:
> > javavmwrapper, OTOH, uses the logic from bsd.java.mk (not
> > reimplementing it) to pick a port that is *already* installed
> > via the ports.
>
> You're right, but if it can't read bsd.port.mk, javavm tries to
> find the JDK itself from line 465 to line 573, that's why I say we
> have two implementations of the lookup algorithm.

Indeed. Moreover, as you said, javavm only does this specific lookup if
there is no bsd.port.mk. No need to have this logic within bsd.java.mk,
because if there is no bsd.port.mk, there is eventually no bsd.java.mk.
:)

> I'm attaching a patch to add documentation to javavm, and to allow
> for a JAVAVM_DRY_RUN environment variable that makes javavm find
> the best suitable JVM and print the corresponding value of
> JAVA_HOME instead of executing it.
[...]
> +# Environment variables affecting the behaviour of this program:
> +#
> +#
> +# JAVA_HOME
> +#
> +# Allows to choose the preferred JVM
> +#
> +#
> +# JAVA_VERSION
> +#
> +# Allows to choose a preferred JVM version

I don't think it's worth it to list those variables here as there is
already a man page for javavm(1) which is quite detailed on the subject
(and it explains the other variables, such as JAVA_OS and JAVA_VENDOR).

> +# JAVAVM_DRY_RUN
> +#
> +# When set, find the best suitable JVM and print the corresponding value of
> +# JAVA_HOME instead of executing it

This info is useful, but it should rather be added directly to the
manpage when we're done implementing the feature.

The patched javavm works fine for me (I tested the latest version).

Herve
 
 
herve.quiroz





PostPosted: 2006-4-19 23:02:00 Top

java-programmer >> Getting JAVA_HOME at runtime Hi Jean-Baptiste,

On Wed, Apr 19, 2006 at 03:40:41PM +0200, Jean-Baptiste Quenot wrote:
> > javavmwrapper, OTOH, uses the logic from bsd.java.mk (not
> > reimplementing it) to pick a port that is *already* installed
> > via the ports.
>
> You're right, but if it can't read bsd.port.mk, javavm tries to
> find the JDK itself from line 465 to line 573, that's why I say we
> have two implementations of the lookup algorithm.

Indeed. Moreover, as you said, javavm only does this specific lookup if
there is no bsd.port.mk. No need to have this logic within bsd.java.mk,
because if there is no bsd.port.mk, there is eventually no bsd.java.mk.
:)

> I'm attaching a patch to add documentation to javavm, and to allow
> for a JAVAVM_DRY_RUN environment variable that makes javavm find
> the best suitable JVM and print the corresponding value of
> JAVA_HOME instead of executing it.
[...]
> +# Environment variables affecting the behaviour of this program:
> +#
> +#
> +# JAVA_HOME
> +#
> +# Allows to choose the preferred JVM
> +#
> +#
> +# JAVA_VERSION
> +#
> +# Allows to choose a preferred JVM version

I don't think it's worth it to list those variables here as there is
already a man page for javavm(1) which is quite detailed on the subject
(and it explains the other variables, such as JAVA_OS and JAVA_VENDOR).

> +# JAVAVM_DRY_RUN
> +#
> +# When set, find the best suitable JVM and print the corresponding value of
> +# JAVA_HOME instead of executing it

This info is useful, but it should rather be added directly to the
manpage when we're done implementing the feature.

The patched javavm works fine for me (I tested the latest version).

Herve
_______________________________________________
email***@***.com mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-java
To unsubscribe, send any mail to "email***@***.com"
 
 
Jean-Baptiste Quenot





PostPosted: 2006-4-19 23:31:00 Top

java-programmer >> Getting JAVA_HOME at runtime * Herve Quiroz:

> This info is useful, but it should rather be added directly to
> the manpage when we're done implementing the feature.

OK I will provide a patch against shell script *and* man page
then.

Thanks for your help,
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/