javavmwrapper behaves differently, whether it sees an installed portstree or not. At runtime it should not make any difference in behavior, whether a portstree is installed / mounted from anywhere or not. This is primarily a problem, if javavmwrapper runs on another machine than it was built on, or the portstree has changed after building. Changing some java settings in /etc/make.conf may also influence the javavm choice. javavmwrapper should rely only on /usr/local/etc/javavms and /usr/local/etc/javavm_opts.conf while choosing the "right" java vm. Fix: Responsible for this unwanted behavior are a couple of lines in javavm shell script which can be simply removed: How-To-Repeat: install both diablo-jdk and openjdk. configure javavmwrapper to prefer openjdk. run "java -version" with portstree in /usr/ports -> diablo-jdk is chosen move (temporarily) /usr/ports anywhere run "java -version" again - openjdk is chosen
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-----
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"
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.