> >If all you want is for the user to specify a "default JVM", then why not > >just let this default JVM be the alternative /usr/bin/java, just like it > >is now? [...] > > IMO the alternative system can only be used in two cases: > * when all apps for the alternative are similar enough to not cause > any damage in scripts (-> awk, sendmail) > * when the alternative is uses interactivly (-> editor) > > IMO java doesn't fit this requirements. ...
We're not talking about using this alternative to run every Java app. 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. > In your 'way', you follow the symlink (just curious: how? ... 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. > >[4 level if clause] > this code will be duplicated in every java package. When I would see > that in java code, the first thing I would do is refactoring the code > and put that into a common place. This is what we are doing with the > findjava code. 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). I'm simply arguing that it should use alternatives for this "default JVM" that you yourself claim it will support. > * User specific JVM will still require some work (env variable?) I *really* hope that findjava will support this. If policy is mandating that packagers rely on a script that cannot support user-specified JVMs at runtime, we will lose valuable functionality for some packages. We will also lose the ability for users to specify non-free JVMs when packagers haven't yet included them in their lists of known working JVMs. > * 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. > * The fallback will result in unrecognised error messages (see above) What is the fallback for findjava then? How will this be any better? > I have hoped that we were over the 'starters'. This last proposal > hasn't generated much heat and I hope that I have the findjava script > ready and will post it together with some test data. I hope that I will > be able to put that all into a bugreport and we can go on from there... I still think that we cannot come to any decision on whether findjava should be mandated until we actually see the script. 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). 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. Ben. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
