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
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?