On 27.03.2010 01:24, Matthew Johnson wrote:
On Fri Mar 26 21:47, Eric Lavarde wrote:OK, I'm not exactly enthusiastic, but I can live with this, as long as the wording of the policy is adapted accordingly. Why I'm not enthusiastic: should I manage to get into Debian yet another Java runtime, which is not compatible with either gcj, nor with openjdk, then the result could be that quite a lot of packages wouldn't be policy compliant anymore, because they wouldn't work with "all" JRE anymore.I personally view adding more JREs as a bad plan. I believe we should be aiming to reduce their number, ideally to one (at least, to one that behaves as /usr/bin/java and that packages depend on; or - one that is _supported_ as /usr/bin/java). After all, despite multiple python interpreters, only one of them is supported as /usr/bin/python.
there is more than one which is supported. only one of them is supported as the default. yes, using alternatives would break the dependencies of packages.
the handling of the java* binaries via alternatives bothers me. we do have update-java-alternatives to help people to ensure consistency with all links, but we cannot rely on these links to build stuff (all our packaging is based on a JAVA_HOME set). Various helpers and scripts do their own selection of the jvm used.
Ideally, every platform should build openjdk-6 (the last build added was the SH4 port), but it requires some porting work which needs to be done (hppa), or backported/merged (bsd). Any help?
Even in openjdk-6 we currently have four different jvm's: - hotspot jit, used on x86 and sparc, with sparc not having upstream support, and unbuildable with b19 - the zero port, an interpreter which is somehow platform independent (except for hppa). - shark (a jit extending zero), currently packaged as openjdk-6-jre-zero on x86, armel, powerpc. - the ARM assembler interpreter, an optimized zero interpreter for ARM. - cacao, a JIT integrated into openjdk-6, currently maybe usable on armel and powerpc. Hmm, these are already five ...For experimenting, you can access the various jvms using the -cacao|-zero|-shark options given to java (and installing the corresponding jre packages).
So the java situation looks more complicated than i.e. the python situation, where we still have one default implementation of the default interpreter.
If you reduce the number of JREs and maybe converge on the one available on most platforms (zero), you'll make java unusable on most platforms because of the performance of the interpreter. If you rely on a JIT, you are bound to the availability of the JIT on a specific architecture (both hotspot and shark (using llvm) not supporting all architectures).
Updating gcj using openjdk instead of classpath might be another way to provide a common jvm for all architectures.
Matthias