Bug 167799

Comment 1 Tilman Keskinoz 2012-05-11 21:09:26 UTC

Responsible Changed
From-To: freebsd-ports-bugs->glewis

over to maintainer

----- Forwarded message from Greg Lewis <glewis@eyesbeyond.com> -----

Date: Thu, 17 May 2012 22:29:38 -0700
From: Greg Lewis <glewis@eyesbeyond.com>
To: freebsd-ports-bugs@freebsd.org
Subject: Re: ports/167799: javavmwrapper-2.3.5 does not always choose the
	right java vm

I think this PR misunderstands what javavm is designed to do and how to
configure it.

One of the main design requirements for javavm was to provide a mechanism
for ports maintainers to be able to get the same JDK at runtime that they
specified when they were building their ports.  Specifically, they can
specify requirements such as version (JAVA_VERSION), vendor (JAVA_VENDOR),
etc., in the shell scripts that launch Java applications and get the same
JDK chosen at run time as was chosen at build time.  The main way this is
done is by using the same logic, i.e. by running those requirements through
bsd.java.mk and using the JDK that it chooses.  Only if the ports tree is
not found does javavm then try and fall back to using some internal logic
to try and pick the same JDK.

In that sense, this patch removes the primary piece of functionality from
javavm by making it not use bsd.java.mk if it's available.  This leaves
only the fallback logic, which can easily get out of sync with how the
ports infrastructure chooses JDKs at build time.

In terms of selecting the JDK, neither javavms, nor javavm_opts.conf is
involved in that.  In particular, javavms is an internally used file that
should just list all the JDKs available.  It is not designed to be edited
by a user.  javavm_opts.conf is just for passing options to particular JDK
instances, it has no bearing on what JDK is chosen.  The way to influence
what JDK you want javavm to choose is to set environment variables like
JAVA_VERSION, etc.

If it is inconvenient to set environment variables, then I would consider
introducing a configuration file that contained those variable settings
that could be sourced by javavm at runtime.

-- 
Greg Lewis                          Email   : glewis@eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis@FreeBSD.org
_______________________________________________
freebsd-ports-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports-bugs
To unsubscribe, send any mail to "freebsd-ports-bugs-unsubscribe@freebsd.org"

----- End forwarded message -----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 18.05.2012 07:29, schrieb Greg Lewis:
> I think this PR misunderstands what javavm is designed to do and
> how to configure it.
> 
> One of the main design requirements for javavm was to provide a
> mechanism for ports maintainers to be able to get the same JDK at
> runtime that they specified when they were building their ports.
> Specifically, they can specify requirements such as version
> (JAVA_VERSION), vendor (JAVA_VENDOR), etc., in the shell scripts
> that launch Java applications and get the same JDK chosen at run
> time as was chosen at build time.  The main way this is done is by
> using the same logic, i.e. by running those requirements through 
> bsd.java.mk and using the JDK that it chooses.  Only if the ports
> tree is not found does javavm then try and fall back to using some
> internal logic to try and pick the same JDK.

Thank you for shedding some light on this topic.

> In that sense, this patch removes the primary piece of
> functionality from javavm by making it not use bsd.java.mk if it's
> available.  This leaves only the fallback logic, which can easily
> get out of sync with how the ports infrastructure chooses JDKs at
> build time.

I firmly believe that it is (and probably will ever be) almost
impossible to synchronize the fallback logic with the port building
framework, so IMHO there is a need for a more predictive behavior, at
least in installations with strictly separated build, test, and
runtime environments, like ours.

> 
> In terms of selecting the JDK, neither javavms, nor
> javavm_opts.conf is involved in that.  In particular, javavms is an
> internally used file that should just list all the JDKs available.
> It is not designed to be edited by a user.  javavm_opts.conf is
> just for passing options to particular JDK instances, it has no
> bearing on what JDK is chosen.  The way to influence what JDK you
> want javavm to choose is to set environment variables like 
> JAVA_VERSION, etc.
> 
> If it is inconvenient to set environment variables, then I would
> consider introducing a configuration file that contained those
> variable settings that could be sourced by javavm at runtime.
> 

This proposal looks to me like a possible solution. These (application
specific) configuration files - sourced by javavm - to set correct
environment variable values at runtime should IMHO already be created
at build time for every java application, so that consistent behavior
can always be guaranteed, even in different runtime environments. The
"bsd.java.mk" part of javavm can then be considered superfluous.

As I already mentioned earlier, any live communication between a
running application and the portstree should be avoided. Otherwise
updating the portstree or changing /etc/make.conf may lead to
unexpected and unpredictable runtime behavior of some installed java
applications.
Furthermore if I now use precompiled packages from freebsd.org
(pkg_add -r), I simply neither know exactly all (java) prerequisites
of that package nor all valid port options at build time.
(Java-) Application specific configuration files created at build time
will IMHO significantly increase reliability and stability at runtime,
At least this modification will IMHO be more tailored to the needs of
an average user.

- -- 
Regards
Alfred Bartsch
Data-Service GmbH
mailto:bartsch@dssgmbh.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+7cMcACgkQ5QGe2JdVf3isAQCgn5LQ4MlPnwr6E5yVJH3h90cz
PWAAmwdqdWKcwxcOeFuFGFI34prx1Ya9
=bfyo
-----END PGP SIGNATURE-----

Comment 4 dfilter service 2012-07-13 06:38:54 UTC

glewis      2012-07-13 05:38:44 UTC

  FreeBSD ports repository

  Modified files:
    java/javavmwrapper   Makefile 
    java/javavmwrapper/src javavm.1 javavmwrapper.sh 
  Log:
  . Make the version numbers consistent so they can be compared correctly.
    E.g. for jdk1.6.0 and openjdk6 will use '6' as the version.
  . Modify the preference order for Java VMs used by the internal fallback
    logic to reflect that openjdk is now the default Java VM rather than diablo.
  . Remove code for Java vendors that are no longer in the ports tree (e.g.
    blackdown, ibm).
  . Remove code for handling version numbers that are no longer present in
    the tree (e.g. only 1.5 and up is supported).
  . Note that openjdk is a native Java VM.
  . If the environment variable JAVAVM_FALLBACK_ONLY is set then only use the
    internal logic to select a Java VM, don't use the ports logic even if the
    ports collection is installed. [1]
  . Update the manual page for JAVAVM_FALLBACK_ONLY.
  . Bump version to 2.4.
  
  PR:             167799 [1]
  
  Revision  Changes    Path
  1.35      +1 -1      ports/java/javavmwrapper/Makefile
  1.14      +11 -1     ports/java/javavmwrapper/src/javavm.1
  1.25      +56 -79    ports/java/javavmwrapper/src/javavmwrapper.sh
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"

Comment 5 Greg Lewis 2012-07-13 06:39:09 UTC

State Changed
From-To: open->closed

I've committed a change which will allow you to set the JAVAVM_FALLBACK_ONLY 
environment variable and have that mean that javavm will only use its 
internal fallback logic for determining the VM to use.