Hallo Ben,
I like academic discusions :)
* Ben Burton wrote:
>> * 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)
>- Personal usage when running your own Java apps, etc. from the
>command-line; this is essentially usage (1) as described above;
True.
>- 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 think the discussion has made it clear that even sun-java-1.4 would
not be enough, to make sure that its 'the same enough' in all cases.
>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).
And this measn that you have to follow the symlinks, which is IMO
something, which simple 'works around' the alternative system.
>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.
Yes and that why we still have the 'you may add a alternative for...'
>> 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).
But it has a two advantages: It will be automagically filtered out, if
it doesn't fit (could be done with symlink following) and the user has
a way to overwrite it (which isn't possible with u-a).
>> /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).
Ok, this is a point. There is a lot etween 'hello world' and a full
featured app like tomcat, but where will you draw the line?
>> 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).
Are you happy if we leave out this variable in the initial
'$HOME/.javarc (like this idea), but it will be mentioned in the man
page, together with a big warning, in which cases it should be used.
>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.
Ok.
>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?
I like the idea, but we have some namespace cluttering then. There
could be the idea, that any 'java' needs a javarc as well and then we
are in trouble...
So are you satisfied with my scripts? Any bugs found?
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]
