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 [EMAIL PROTECTED] "Wer nicht fragt, bleibt dumm." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
