There was one from blackdown, but it has security issues. If you have time and like to code at a fairly low level, I can help with a possible light-weight substitute, but I haven't had the time to make it work (endian issues and pointer misalignment and just what assembly level semaphores it wants). It's a disgrace that sun won't support their language on their architecture on a system they support, but I can't fix that.

I am a junior level sysadmin/engineer... I've forgotten most of my C due to lack of use lol so I couldn't help you with what I assume is assembly level coding. I'd be all for it if I could code well. Hopefully someone out there will take on this task...

probably because sun-jdk is binary and you just can't run x86 binaries on a sparc

However if you have a program written in java and you want to run it on linux/sparc you can try your luck with gcj/gij(compile gcc with gcj useflag, http://gcc.gnu.org/java/faq.html)._________________Black Holes are created when God divides by zero!

I'm neither a Gentoo nor a Debian/Ubuntu user but why would we settle for some older, unsupported SPARC JVM when we could just as well get the OpenJDK working on SPARC. The code is there for Linux and for SPARC, we only have to get the combination working.

Thanks for the information. I think that there are two difficulties: (1) Assembly language will likely need some conversion; (2) More difficult: I am sure sparc/solaris java assumes 64-but user mode. Sparc/linux is 32-bit user mode. This can cause problems unless the sun developers took care to use conditional compilation options.

Please see Bug #159780 from comment 41 (https://bugs.gentoo.org/show_bug.cgi?id=159780#41 ) on. It looks as if IcedTea can work as a java engine on sparc, thanks to Dylan Wakefield. Please test it if you are interested in java and post results here. I am aiming to get this into the Gentoo mainstream, and would just like to have a bit of feedback first.

I had to emerge dev-java/ecj-gcj and sys-devel/gcc-4.5.3-r1 for bootstrapping and to fulfill all requirements of the `configure' script of icedtea6-1.10.3 (several java apis can be downloaded in binary form). Then I encounterd two problems:

I had a ClassNotFoundException at the beginning of the build process and found a solution with help of

The second problem was a compiler error because the newer gcc-versions produce new warnings for some old-style-code in the jdk-sources which are converted into compiler errors if -Werror is set as option. The sources of the jdk are not ready for these warnings. The solution is therefore to get rid of the -Werror option. I have found a patch for this issue in an older version of icedTea (http://osdir.com/ml/attachments/txtMUBogtElg3.txt) which is however not included in icedtea6-1.10.3. As with the issue before I applied the ideas of this patch manually to the file targets which are found under a slightly different location however. Then finally everything worked.

The new jdk makes a quite good impression. My favorite java application are running stable, e.g. intelliJ-IDEA. I have copied a jboss-5.1.0 from an opensolaris installation of another hard drive of the same machine to the gentoo-installation and found to my complete surprise that the startup time of this empty jboss takes ~2:05min on opensolaris (2009.06, sun-jdk-1.6.0_13) whereas only ~1:35min on gentoo (2.6.39-gentoo-r3) .

My gentoo installation was compiled with gcc-4.4.5 but in order to compile the icedtea6-jdk I had to emerge gcc-4.5.3. Later I tried to upgrade the whole system with the new compiler but had no success (got an ugly compiler error late in `emerge -ev world'). Therfore I switched back to stable gcc-4.4.5 and rebuilt the icedtea6-jdk two times based on the output of the previous build cycle using

Now I have consistent binaries and all packages emerged for the first build cycle, compiled with gcc-4.5.3, should be eligible for unmerge. The testsuite of the jdk gives for me now the following results in good agreement with the results reported on linuxfromscratch:

As several links from my above posts are broken in the meanwhile I have decided to make an update of my jdk and offer the complete build as a download on a shared storage (if there are possibilities to do it with gentoo please let me know).

The build was made with the jdk 1.6.0_22 of my above posts and icedtea6-1.11.3 which produces a 1.6.0_24 jdk. This time I have found only one problem: several undefined symbols in the file openjdk/hotspot/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp in function 'print_register_info'. By analyzing the code of this file - mainly function 'print_context' - I have tried the following patch successfully:

# point to the old build-jdk and rhino1_7R3
./configure --disable-bootstrap --with-jdk-home=/opt/icedtea6 --with-rhino=$HOME/work/java/rhino1_7R3/js.jar

make

With the provided binary version of the jdk 1.6.0_24 you can build your own jdk in this manner.

At the end a 'make check' will run the test suite. Be sure to disable the power management and screensaver of your workstation first and don't touch mouse and keyboard when the awt and swing tests are executed. The test suite takes on my SB-1500 more than 5 hours:

!!! The multilib configuration is experimental. Use it at your own risk. !!!

I have performed a clean installation of gentoo/sparc/multilib on a spare disk of my SB-1500 using a stage3-multilib-tarball. I wanted to build icedtea6-1.11.3 for the 64-bit environment. With 64-bit-java you can overcome the 4g memory restriction of 32-bit-java which manifests in responds like this:

After the successful installation of multilib I have emerged several additional packages in 64-bit mode which are required for building icedtea6-openjdk. I followed the concept of an alternate ROOT environment variable (-> `man emerge') and set the following environment variables:

If you emerge libraries with this environment the binaries will be installed in 64-bit-form under the directory /opt/icedtea6-1.11.3-libs and have no conflicts with existing libraries of the same package in 32-bit-form installed under /.

The build process proceeded in stop-and-go-mode. When a library was missing, the build process interrupted, I emerged the missing library in 64-bit-mode and restarted the build. I had no problems emerging the 64-bit-libraries !

(In order to run the openjdk-test-suite I had to install X11 in 32-bit-mode as usual, but no desktop environment.)

The price for 64-bit-java is however a significant loss of performance. The jdk-part of the test-suite takes for me ~4:55h in 32-bit-mode and ~7:30h in 64-bit-mode. The startup time of an empty jboss-5.1.0 is on my SB-1500 1:30min in 32-bit-mode and 3min in 64-bit-mode.

!!! The multilib configuration is experimental. Use it at your own risk. !!!