Re: findjava requirement (was: 4. RfD for a new debian java policy)
> IMO the 'alternative system' is not used for this. Looking what
> alternatives are installed in my system, they are either
> * editors or other interactive things (telnet, www-browser)
> * different version of the same tool (autoconf, gcc, shells)
> * apps which do not require commandline apps (x-session-manager)
> * things which behave the same (x-cursor-theme, awk)
A /usr/bin/java alternative would be used for two things:
- Personal usage when running your own Java apps, etc. from the
command-line; this is essentially usage (1) as described above;
- Use in startup scripts; this is essentially usage (4), given that
it will only be used if the package manintainer has already verified
that it works (and so it's "the same enough").
I realise that different JVMs have inconsistencies, which is why they
shouldn't be used blindly in startup scripts unless they're known to work
(but this has already been resolved).
But there are many, many apps for which a simple JVM with simple options
is enough. In this case when I'm working with Java on my own at the
command-line I want to have the intuitively named /usr/bin/java on my system.
Btw, we should observe that this part of the argument has become
academic since I've already indicated my satisfaction with the global
/etc/whateverrc file.
> The standard JVM should not be used in any package
Unless it's known to work. Which you're advocating anyway with
/etc/findjava's $PREVERRED_VM (which is essentially the same idea,
i.e,. a system-level standard JVM).
> /usr/bin/java* is only for Hello World.
This is nonsense. You cannot just reduce all non-package-related
non-complex-command-line usages to Hello World. There are plenty of
cases in between (which I use on a regular basis).
> > With the /etc/javafind proposal, you'd either ship with no default
> > at all or you'd ship with a default that might not be installed on
> > the system.
>
> No. The app becomes the most useable installed VM: The findjava script
> will always return a valid JVM. It will return the first available in
> the searchlist, so the maintainer of the list can make some nice
> preferences.
Sure.
> >I'd in fact suggest that we don't allow JAVA_OVERWRITE_VM in the config
> >files - just the safer PREFERRED_VM or whatever it was - and only allow
> >JAVA_OVERWRITE_VM in the environment, so that it's used on a
> >case-by-case basis.
>
> IMO it can be nice to have it. I would like to be able to test more
> than one package, if I install a new (unfree) VM and would be slighly
> fed up to type it in every xterm I open. It doesn't really matter if
> I have to add this to .bash_profile or .findjavarc...
As you say, this is just as easily done with a personal environment
variable, though this makes it more difficult to enforce this testing on
other users of the system (which I claim is a good thing).
> >I'd even go so far as to say that each java app's man page should
> >contain a link to this documentation
>
> As they use the findjava script they should.
Note that this should not be a link to "man findjava", which end-users
shouldn't care about at all. Rather a link to "man findjavarc" or
whatever.
Hmm, given that: it is worth making the config files something more
obvious like ~/.javarc, /etc/javarc ? i.e., make them look more like
global config files that findjava just happens to rely on?
b.
Reply to: