The long way for Java on Gentoo/FreeBSD

Even though the Gentoo/FreeBSD team had support for Java for a while now, thanks to Timothy who prepared the first ebuilds for the Diablo JRE and JDK, the actual support for Java wasn’t an easy task.

The first problem is that the Diablo software is only for version 1.5 of Sun’s Java implementation (Java5), so the old Generation 1 ebuilds simply didn’t work, and just recently the Gentoo Java team (with a huge effort) ported most of the ebuilds in the tree to Generation 2 by moving away those that weren’t ported already.

Another problem is to actually get a few packages fixed, as it’s common even more for Java than other classes of packages that the find or cp commands get their parameters in the wrong order. This says nothing about the skills of the Java Team (which is a really good and skilled team), it’s just that for Java there are almost no make install commands to run, so the ebuilds have to do their magic by hand.

Then there is the «little» problem that Sun Java 1.5 is quite old, and the Diablo project hasn’t released anything in quite a few months, so the only hope to get a working modern Java on FreeBSD is represented by OpenJDK (if Sun decided to actually apply my patches, or at least review them).

Nevertheless, even with these problems we were able to provide working Tomcat and NetBeans on Gentoo/FreeBSD, as well as Azureus, JRisk and a few other programs, with all their dependencies. Yesterday I started working on getting the new NetBeans 6.0 ebuild from the java-experimental overlay to work, but this proved to be a wicked work.

Beside the huge amount of new dependencies, most of which comes from the main tree, but a few came from the overlays too, the new ebuild has a dependency over dev-java/proguard which in turn depends on dev-java/sun-j2me-bin that, as the name suggest, is a binary, this time not a Java binary, but an ELF Linux binary.

I think I read that J2ME was being opensourced by Sun a while before OpenJDK, but I haven’t been able to find the sources, to try getting a from-source version of it working, solving the problem, so for now, we’re stuck.

In the mean time, for what concerns OpenJDK, I have quite a few patches here that are not applied on the java-experimental overlay either; beside one to fix the executable stack of the ASM source files (Sun fixes this after build, I suppose), there’s a warning fix for GCC 4.2, a patch to use libstdc++ dynamically rather than statically, one to use the system copy of libXinerama, rather than the internal copy, one to link libfontconfig directly rather than by dlopen(), and in particular, a big one that fixes the locale problem, setting the language to the value set by LC_MESSAGES rather than LC_CTYPE; this way when running a Java application with LC_CTYPE set to Italian, and LC_MESSAGES set to English, the interface doesn’t come up in Italian.

And keeping on Sun topic, I’m currently running Solaris Express installation on VMware server, waiting for VirtualBox to fix their PCnet emulation (no, it’s not Solaris not supporting the emulated hardware, it’s the emulated hardware that is not good enough).