Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Matt,
* Matt Zimmerman wrote:
>> This interface is not for the free ones but only for the sun complient
>> ones (Sun, BD, IBM). The rest will be handled independently.
>Independently how? I admit I am primarily interested in how java VMs and
>development tools in Debian will work with java software in Debian, and not
>with commercial JVMs, development tools or software.
Currently you can't depend on /usr/bin/java, because it can be
anything from j2sdk1.4.2 to kaffe/sablevm, which don't even have the
same comandline interface, save the same API or lang spec.
To make this easier to control, you can depend on the 'unfree
interface', which will be the same for each unfree VM of a certain
version. For the free once, you have to test each one. So basicly you
will start your java app like this:
if [ -x /usr/bin/java-1.4 ] ; then
JAVACMD="/usr/bin/java-1.4"
CP_OPTION="-classpath"
elif [ -x /usr/bin/kaffe-1.1 ] ; then
JAVACMD="/usr/bin/kaffe-1.1"
CP_OPTION="-addclasspath" # needed in the kaffe 1.0 release
else
echo "No java found! Aborting..."
exit 1
fi
It would be nice to factor this code into a common starting class or a
programm, who handle such things. This could then also be used to test
packages with 'new' JVM.
The problem with the current apprach is, that /usr/bin/java will some
day be to far away from the requirement of java apps. Policy seems to
have been made around java 1.1.8 to 1.3 transition, now we have 1.4,
which adds for example the assert keyword. The next version of eclipse
will almost certainly require a 1.4 JVM.
The aproach above is still not 100% bulletproof, but much better than
todays
if ["x$JAVA_HOME" != "x" ] ; then
JAVACMD="$JAVA_HOME/bin/java"
else
JAVACMD="/usr/bin/java"
fi
which will break when JAVA_HOME isn't set. This is made slightly more
failsave with the inclusion of the BD /usr/lib/*/bin/java in the
searchpath.
See the ant or eclipse startscript. Tomcat4 seems even not be
startable without JAVA_HOME set (only set in the init.d script, not
when called regulary via /usr/bin/tomcat4 (Policy violation)).
This aproach could be made even more bullet proof, if the app package
Conflicts with the last known *not* working version of a JVM. For
example kaffe 1.0.6 does not work, but 1.1.1 will work, the package
should Conflicts: kaffe (<<1.1) and so on for each free VM.
Build prozess will fail, if you use equivs or mpkg-j2sdk to get suns
Java installed, even if from the spec level and API version, everything
will work.
mpkg-j2sdk is a really nice package, which could be used to setup this
'unfree' interface. Advertiesed in the FAQ and in the ML, it will make
java handling a lot easier for our users. But with the current java
policy, this will not work, as the current interface (/usr/bin/java,
'comandline compatible' (to which version?)) is to weak to get
anything done with it.
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: