findjava requirement (was: 4. RfD for a new debian java policy)
> >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. :)
Reply to: