Did java 5+ ever work on 32 bit SPARC machines?

Basically the question should sound "Did java 5_ ever work on 32 bit SPARC machines?", because for the plus part I already know the answer. Up to now it didn't.

Here goes the story:


Wondering if could use some large application to test the emulation, I tried Java and Oracle Lite.

I went to the Oracle site and downloaded Java 6SE, as it's the only directly downloadable version. The installer worked ok, but when I tried

# java -version
SPARC V8 processor detected; Server compiler requires V9 or better.
Use Client compiler on V8 processors.
Could not create the Java virtual machine.

Oh well, I need explicitly specify the client compiler, which is pretty stupid

since Java can auto-detect that there is the only one supported, but, ok, let's try it.

# java -client -version
SPARC V8 processor detected; Server compiler requires V9 or better.
Use Client compiler on V8 processors.
Could not create the Java virtual machine.

What?!? Ok, google is my friend. There is a public bug #6922500, which tells that Java 6

can not work on SPARCStation-5 (and obviously all other 32 bit machines). The bug is closed

as a duplicate of #6921472, which is supposedly fixed in Java 7 (!) b102. Can't find b102,

and the current Java 7 version for 32 bit SPARC is compiled for V8plus.

I wonder why do they offer Java 6+ for 32 bit SPARC at all? It obviously can work only on 64

bit machines.

Now everyone blames Oracle, but the first version of Java 6 was released long before Oracle

bought it. It was Sun who started phoning it in.

Ok anyway, I tried Java 5 and at least "java -version" seemed to work. But an attempt to

start Oracle Lite produces a core dump mostly consisting of the same calls:

ef1b372c __1cIos_sleep6Fxi_i_ (0, 1, 0, ff725e56, 171, 6000) + c
 ef1b1888 __1cCosFsleep6FpnGThread_xi_i_ (0, 0, 1, 4, 4, ef60a9f8) + 284
 ef241d4c __1cCosJyield_all6Fi_v_ (ef670e00, ef608a30, 1056d8, ff725e56, 171, ef5ee000) + 25c
 e9000784 ???????? (e4f5eb08, 1, ef608a28, ef608a30, 2cdc, ef5ee000)
 ef1b37a0 __1cIos_sleep6Fxi_i_ (1, ef608a30, 0, 6398, 0, e9000740) + 80
 ef0ea85c __1cMgetTimeNanos6F_x_ (e4f71bb8, 1, ef608a28, ef608a30, 2cdc, ef5ee000) + 120
 ef1b37a0 __1cIos_sleep6Fxi_i_ (0, 0, 0, 1, 171, 7fffffff) + 80
 ef1b1888 __1cCosFsleep6FpnGThread_xi_i_ (0, 0, 1, 4, 4, ef60a9f8) + 284

Is there a chance that it fails due to a bug in qemu-sparc and not in Java?