Re: findjava requirement (was: 4. RfD for a new debian java policy)
Hallo Ben,
* Ben Burton wrote:
>We're talking about using it by default _if_and_only_if_ it's in the
>list of known working JVMs. This is exactly the same thing you were
>wanting from the findjava script. Your argument about incompatible JVMs
>is not relevant to the point at hand, and if it were relevant it could be
>used against the findjava proposal in exactly the same way.
IMO you don't need to use teh alternative system, if you just 'work
around' it. YMMV...
[follow symlinks]
>That would depend on the language in which the script were written.
>The javareg that I wrote a couple of years ago now to deal with some of
>the java mess was written in perl, and so it used the built-in
>readlink() function.
Seems that I have to learn perl some day... sh is currently my only
scripting language...
>Sure. I'm not arguing that the findjava script is a bad idea (though of
>course it's hard to argue until we've actually seen it).
You can now:
http://www.katzien.de/debian/java/
It includes java-config, update-java-config and findjava. Also, there
is my 'testbed', with all the 'java-config files'.
To test findjava do the following:
export JAVA_CONFIG_DIR=`pwd`
bash findjava beta-vm hallo-vm
bash findjava --client beta-vm hallo-vm
bash findjava --server beta-vm hallo-vm
export JAVA_OVERWRITE_VM="/bin/false --server"
bash findjava
See the scripts for the actual implementation... Its almost three in
the morning now and I'm not good at documentation issues right now :)
The other two scripts are the same as the last time, just renamed
them. I hope they still work...
>> * User specific JVM will still require some work (env variable?)
>I *really* hope that findjava will support this.
It's supported, but I don'T think that should be the default.
findjava does the following now:
* look into env for a JAVA_OVERWRITE_VM
* source the $HOME/.findjavarc and look into env for JAVA_OVERWRITE_VM
* put the user pref java package first into teh serach path
* search the searchpath for a working VM
* first with 'OPTION' (server and client just now)
* just teh first available
*NO FALLBACK!
Thsi wil make it possible for users to specify one default >VM, and
overwrite that wit a single 'export ...' line.
>> * In x% (depends on the VM, which is setup as 'java') of the cases, the
>> 'lookup' will come up with a 'not working' VM -> wasted.
>Compared to the startup time of the JVM itself, I'm sure this wasted
>lookup time will be insignificant.
True.
>> * The fallback will result in unrecognised error messages (see above)
>What is the fallback for findjava then? How will this be any better?
Nothing: It will at least give proper error messages... It shouldn't
happen with package management though.
>I still think that we cannot come to any decision on whether findjava
>should be mandated until we actually see the script.
So... :)
>I'm not trying to rush you btw, it's just a lot easier to discuss
>technical matters such as this when we have specific details. It's not
>just the implementation - we still don't even know the interface with
>which packagers will be using findjava (unless I've missed something
>buried in one of these threads).
The 'findjava' algo was described in one of my mail. I'Ve just
implemented it with the only exceptuion that a 'before sourceing the
env is already searched for a overwrite VM, so that 'per start
changes' are possible.
>And as for being "over the starters", the "must use findjava" clause
>was only added in the fourth revision, which is why I've only started
>arguing about it now.
But it was discussed much longer :) Anyway, here you go...
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: