Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 12 May 2012 10:54:39 +0200
From:      Alfred Bartsch <bartsch@dssgmbh.de>
To:        Greg Lewis <glewis@eyesbeyond.com>
Cc:        freebsd-java@freebsd.org
Subject:   Re: how does "javavms" work?
Message-ID:  <4FAE254F.3010208@dssgmbh.de>
In-Reply-To: <20120511145852.GA8563@misty.eyesbeyond.com>
References:  <B10943F5-3648-4993-B5C4-A0C96CFF604B@shire.net> <4FAD07BC.2090808@dssgmbh.de> <20120511145852.GA8563@misty.eyesbeyond.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Am 11.05.2012 16:58, schrieb Greg Lewis:
> On Fri, May 11, 2012 at 02:36:12PM +0200, Alfred Bartsch wrote:
>> Am 27.04.2012 20:53, schrieb Chad Leigh Shire.Net LLC:
>>> Hi
>>>
>>> Not the behind the scenes really.   Just how do I use it?
>>>
>>> I installed OpenJDK7 from ports.  As part of that it installed the
>>> Diablo stuff (Java 6).
>>>
>>> the /usr/local/etc/javavms  file listed both.  But when I edited
>>> this file to only have the OKDK 7 version, it still runs the Diable
>>> JDK 6 stuff when I type "java" at the command line.
>>>
>>> I read the man file on javavms and used registervm and unregistervm
>>> and javavms only lists the OpenJDK 7 version but if I do
>>>
>>> # java -version java version "1.6.0_07" Diablo Java(TM) SE Runtime
>>> Environment (build 1.6.0_07-b02) Diablo Java HotSpot(TM) 64-Bit
>>> Server VM (build 10.0-b23, mixed mode) #
>>>
>>
>> Normally, the Diablo stuff is installed as a build dependency to
>> compile the openjdk stuff, and can safely be removed afterwards.
>> But you may keep both JVMS, or you may install even some more.
>> In these cases javavmwrapper kicks in and lets you choose your
>> preferred JVM.
>>
>> Unfortunately, javavmwrapper behaves differently, whether it sees an
>> installed portstree (/usr/ports/Mk/bsd.java.mk) or not.
>> It is my experience that the wanted priority of JVMs due to
>> /usr/local/etc/javavms is only guaranteed, if there is no portstree
>> available.
>>
>> So I decided to patch the javavm wrapper skript
>> (/usr/local/bin/javavm) to remove these unwanted features. Now
>> everything works for me as expected.
>>
>> The attached patch file applies to an installed javavmwrapper-2.3.5
>> port. You may alternatively just remove those lines from the script file.
>>
>> HTH
>>
>> P.S.: I'm thinking of filing a PR, since it looks like a bug.
> 
> It's definitely a feature rather than a bug, see javavm(1).

Yes, you are right, if you solely look at the manpage.
IMHO inconsistent behavior should always be treated as a bug (==
unwanted feature), and yes, after updating the port, the manpage should
also be modified. It now reads:

...
This selection process is usually achieved through the use of
/usr/ports/Mk/bsd.java.mk.  However, if this is not present then javavm
will use its own internal selection process which is designed to behave
almost identically.
...

So there is no need of two concurrent selection processes, or am I
missing something?

As the portstree is a (fast) moving target, I'm convinced that it is
practically impossible to always synchronize the internal selection
process of javavmwrapper with the complex port building framework.
IMHO port building and running environment should be strictly separated,
without any live interaction.

> 
> There are a number of knobs in the way of environment variables that you
> can use to fiddle with the precedence of JVMs.
> 
> This is not to say javavm couldn't use a little updating.
> 

For the sake of reduced complexity and enhanced stability, IMHO removing
the use of bsd.java.mk by javavmwrapper is the way to go, YMMV.

BTW: I submitted a PR concerning this problem:
http://www.freebsd.org/cgi/query-pr.cgi?pr=167799
-- 
Alfred Bartsch
Data-Service GmbH
mailto:bartsch@dssgmbh.de



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FAE254F.3010208>