[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Use of update-alternatives or JAVA_HOME (was: Experience in converting to GCJ)



Hallo Matt,

* Matt Zimmerman wrote:
>JAVA_HOME seems silly in Debian, where we have alternatives to manage these
>things.  I wish it would go away.

I do not!

The current update-alternatives system isn't working, when you don't
have a way to prevent 'not fit to the work' /usr/bin/java to use it.

Curently my /usr/bin/java is assigned to the blackdown packages, but
almost eveywhere else I use a more up2date jdk (all of them
unfortunatelly not even managing u-a).

It would be nice, if we really get a method to get a working java
binary, which fits the need of the calling package (meaning with
respect to API completenes, language level and so on). /usr/bin/java
can be something like a (currently) outdated sableVM or kaffe, gcj,
which only has a interpreter mode, or BlackDown Java. Or, if the user
has taken steps and installed (or simple overwritten) another java
(SUN, IBM).

I have my package recognice JAVA_HOME for this (it can be set in the
config file, but basicly any set JAVA_HOME is fine).

What I would like to see:

* add a script/way to recognise/install/make known any installed
  /bin/java, together with some rules/infos, what cpabilities this 
  java has.
* add a script to java-common, which returns a appropriated java, based on
  . version and api needed
  . user settings in JAVA_HOME

Same goes for javac (sun javac should be the same as ibm javac or BD
javac or jikes. Same should go for the java compiler, which is part of
eclipse). It would be nice, if we could get mpkg-j2sdk to include all
this into the outputed package (somehow I start liking this package a
lot :) Maybe the maintainer would like to upload it to the alioth
project to be maintained, and finally integrated into such a thing,
there?)

Would it make sense to implement such script and sometime in the future
make this java-policy? I really like this idea and also the 'get a
defined classpath from a script based on pakage dependencies' (see my
other mail from some days back).

Jan
-- 
Jan Schulz                     jasc@gmx.net
     "Wer nicht fragt, bleibt dumm."



Reply to: