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.