[arch-general] Concurrent java environments

[Ondřej Kučera]

Hi,

> I see a HUGE headache is asking the user to deal with "changing paths"
> just so a few users can have two java implementations installed. Or
> even worse asking some sort of software to 'automagically' switch such
> declarations. there is nothing but grief in going that route with
> little to gain except for those highly specific usages of a untypical
> and quite unusual user such as yourself.
> 
> i.e. There is nothing whatsoever K.I.S.S. in what you are asking for.
> And ArchLinux is *very* SPECIFICALLY a K.I.S.S. style distribution.
> 
> however all is not lost for you since there *IS* both abs AND a way to
> track specialized PKGBUILDs on specific and particular machines. A
> user such as yourself CAN (!) choose to do the things YOU desire
> without asking Arch to accommodate what you ask for. i.e. You can do
> this for yourself quite easily using the Arch-way once you determine
> EXACTLY how to accomplish your configuration. I would suggest you
> read up on customizing PKGBUILDs so you can facilitate YOUR specific
> needs.


I think you misunderstood my intentions. I certainly don't want users
to deal with changing paths if that was what it took. But I don't think
this is necessary. The way I see it is this: now users can have one and
only one java implementation. They can choose whether it is based on
GNU's gcj+classpath or Sun's jre/jdk. Either way as long is the java
application is "sane" and doesn't need Java 6 features (which are afaik
not included in gcj), it will run OK.

If Arch provided a way to have both environments installed, nothing
needs to be changed for normal users. They would choose one of the
environments and everything would run as smoothly as it does now,
that's the beauty of it and I don't see where it contradicts KISS.

Only some users who want to have more choice would install both
environments. There would have to be one default, frankly I don't care
which but probably it would be easier if it was the GNU's because it is
in /usr/bin. If such an advanced user needed to run some application
under Sun's java, they would probably only need to write a simple
script which would put /opt/java/bin at the start of $PATH and perhaps
set $JAVA_HOME. But this wouldn't have to be done by all users like you
were saying, I would never suggest something like that.

So actually I disagree, I think what I'm asking still complies to KISS.
I mean one of the points of using Linux is to have a choice - you can
choose your distribution, you can choose your favorite video player,
you can choose your favorite PDF reader and you can choose to install
three or five of them so that you can switch if you have a video file
that your favorite player is unable to play or a PDF file that your
favorite PDF reader has trouble printing. One of the reasons I chose
ArchLinux was because it has so many packages available and most of
them I can have installed at the same time. That's why I'm surprised
that such a decision was taken not because there was some technical
difficulty but because somebody felt that (almost) no one needs more
than one java.

Yes you're right, there is ABS and I can just rebuild my own jre/jdk
packages. The only problem is - one of the other reasons why I chose
ArchLinux was that the major "everyday" packages are prepared and I
don't have to compile them myself. And it feels rather strange (and
actually this I find a little contradictory to KISS) having to rebuild
both packages with the only change to the PKGBUILDs in the way that I
would change their "conflicts" line (perhaps I could actually use the
binary packages and tell pacman to ignore dependencies).

In conclusion, I don't want to fight or argue or be offensive in any
way. If I'm missing something important that would make life of other
users more complicated, please tell me. But so far I don't see what it
is in my request (actually it started as more of a question really)
that would complicate things for users that want to have only one java
installed (which would be probably the most of them).

Ondřej


-- 
Regards,
Ondřej Kučera