Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
What interface do you suggest? The discussion her pretty much showed,
that you can't rely on anything. This would mean:
* -classpath is probably save (-cp already not...)
I think we should define an interface in the Java policy, then write
wrappers for the different compilers, and install the wrappers as the
alternative (this is already done for jikes-* at least and for the gij
JVM). So we can indeed handle -cp in the wrappers.
A precise interface should be discussed together. Off my head:
-classpath, -cp, -sourcepath, -O, -d, -g, -deprecation
If a feature is not implemented at all by a compiler, the wrapper should
print a warning, and proceed (in particular, -g, -O and -deprecation are
pretty harmless to ignore). We would also submit a feature request
upstream for that feature.
I agree that we cannot just say " if they are command-line compatible
with Sun's JDK javac", as this is a moving target. The list of options
must be in the Java policy.
* setting up rt.jar? in javac or in the calling script? The script
doesn't know the location, so we would be better off with
/usr/lib/java-dev-env, which would be relative easy to maintain.
rt.jar could be defined by default, but overridable with -bootclasspath
(handled in the wrapper if necessary). This matches Sun's javac
behaviour, so it should make more existing scripts work out of the box
on Debian.
Thanks for this reply!
Thanks for your efforts to improve Java on Debian!
Daniel
Reply to: