GNU/Andrew’s Blog

We are proud to announce the release of IcedTea 1.7.

The IcedTea project provides a harness to build the source code from
OpenJDK (http://openjdk.java.net) using Free Software build tools and
provides replacements libraries for the binary plugs with code from the
GNU Classpath project. More information on IcedTea can be found at
http://icedtea.classpath.org

What’s New?
—————–
IcedTea is based on the hard work of a lot of people that contributed to IcedTea6 (see the recent announcement of 1.2) and OpenJDK. The following noteworthy changes are included in this release (summarised by Mark Wielaard):

- Paul Hohensee published a GNU/Linux hotspot Sparc port and Matthias Klose integrated it into IcedTea.
- Keith Seiths and Andrew Haley made fixes to the awt color package so that it now provides the lcms library with PYCC and LINEAR_RGB ICC
profiles, fixing several applications that did complex color transformations.
- Karl Helgason wrote a midi software synthesizer called Gervill that
is now integrated in IcedTea so that javax.sound.midi support works
now. Mark Wielaard integrated it and made some fixes so that it works
better with javax.sound.sampled.
- Jonathan Gibbons released a free version of jtreg, which was imported into IcedTea by Mark Wielaard so that a make check now runs all the
functional unit tests integrated into OpenJDK.
- Joshua Sumali made lots of fixes to the javaws/netx support. Including improved security, namely catching Socket permissions during runtime,
implementing the remaining JNLP services api (PrintService and JNLPRandomAccessFile), and applet focusing bug fixes, so now netx
plays nice with gcjwebplugin.
- Kelly O’Hair resolved the license issues with the (j)hat tool which is now integrated.
- Lillian Angel and Tom Fitzsimmons added several .desktop files for the various tools included for better GNU/Linux desktop integration.
- Thomas Fitzsimmons rewrote the cacert support to resolve issues with applications like Glashfish and Eclipse which access the keystore
directly.
- Lillian Angel made lots of bug fixes to the packaging and integration support, include improving the font support.
- IcedTea6 1.2 and IcedTea[7] 1.7 are completely synced up again thanks to Andrew John Hughes.
- Andrew also did all the work to make sure IcedTea[7] is now based on OpenJDK7 b26 as released by Xiomara Jayasena.
- Thomas Fitzsimmons rewrote the certificate keystore support.
- Christian Thalinger made various cacao integration fixes.

—————–

The tarball can be downloaded here:

http://icedtea.classpath.org/download/source/icedtea-1.7.tar.gz

The following people helped with this release:
Lillian Angel, Gary Benson, Thomas Fitzsimmons, Andrew Haley, Andrew John Hughes, Matthias Klose, Dan Munckton, Parag Nemade, Keith Seitz, Joshua Sumali, Christian Thalinger, Mark Wielaard, Yi Zhan

We would also like to thank the bug reporters and testers!

Full build requirements and instructions can be found in the INSTALL
file in the top-level directory of the release. However,

$ ./configure
$ make

should be a good start.

Congratulations to the IcedTea team (Lillian Angel, Gary Benson, Tom Fitzsimmons, Joshua Sumali, Andrew Haley, Mark Wielaard) on another release. The OpenJDK version is only one drop further on (b09 as opposed to b08) but there are lots of other IcedTea related changes including the import of MIDI support via Gervill and a Linux/SPARC HotSpot port, not to mention numerous fixes and jtreg-based testing. Gentoo users can already find an ebuild for this in my overlay: http://fuseyism.com/hg/libre_java_overlay.

Unfortunately, creating this ebuild immediately showed up a few issues with the release. The first was rather peculiar, it seems the jar executable from IcedTea 6 1.1 couldn’t handle the @ option used to build the rt.jar file:

(cd /var/tmp/portage/dev-java/icedtea6-1.2/work/icedtea6-1.2/openjdk-ecj/control/build/linux-amd64/classes
&& /bin/cat /var/tmp/portage/dev-java/icedtea6-1.2/work/icedtea6-1.2/openjdk-ecj/control/build/linux-amd64/tmp/jarfilelists/rt_jar_list
| /usr/lib/jvm/icedtea6-1.1/bin/jar c0mf@
/var/tmp/portage/dev-java/icedtea6-1.2/work/icedtea6-1.2/openjdk-ecj/control/build/linux-amd64/tmp/manifest.tmp
/var/tmp/portage/dev-java/icedtea6-1.2/work/icedtea6-1.2/openjdk-ecj/control/build/linux-amd64/tmp/rt-orig.jar
           -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m
-J-XX:MaxPermSize=160m)
Illegal option: @
Usage: jar {ctxui}[vfm0Me] [jar-file] [manifest-file] [entry-point]
[-C dir] files ...

Interestingly, using gjar does work, so for the time being I’ve enforced the use of gcj-4.3 in the ebuild, and used gjar from this. Patching it so that it becomes /usr/lib/jvm/icedtea6-1.1/bin/jar c0mf should also work.

The other issue I ran into was with the plugin option. Gentoo’s econf system specifies all the configure options it uses even if the values are the defaults, due to the way it is automated. So even though the plugin is enabled by default, –enable-gcjwebplugin still gets passed to the build. However, it seems this actually disables it for IcedTea6. I patched this as:

diff -r 3fe8a0881e86 configure.ac
--- a/configure.ac      Wed May 28 11:29:51 2008 -0400
+++ b/configure.ac      Fri May 30 00:53:44 2008 +0100
@@ -101,13 +101,13 @@ AC_ARG_ENABLE([gcjwebplugin],
 AC_ARG_ENABLE([gcjwebplugin],
              [AS_HELP_STRING([--disable-gcjwebplugin],
                              [Disable compilation of browser plugin])],
-             [ENABLE_PLUGIN="$val"], [ENABLE_PLUGIN='yes'])
+             [ENABLE_PLUGIN="${enableval}"], [ENABLE_PLUGIN='yes'])
 AC_SUBST(ENABLE_PLUGIN)

 AC_ARG_ENABLE([docs],
              [AS_HELP_STRING([--disable-docs],
                              [Disable generation of documentation])],
-             [ENABLE_DOCS="$val"], [ENABLE_DOCS='yes'])
+             [ENABLE_DOCS="${enableval}"], [ENABLE_DOCS='yes'])
 AM_CONDITIONAL([ENABLE_DOCS], [test x$ENABLE_DOCS = xyes])

 AC_ARG_WITH([icedtea],

This wouldn’t have been noticed because usually you either stick with the default (which does turn on the plugin) or, if an option is specified, you disable it (which happens). The problem is that specifying either form of the gcjwebplugin option disables it, including the one that’s meant to enable it.

With these two issues fixed, IcedTea6 1.2 can be installed on Gentoo.

It seems a lot of projects and distributions are seeing new releases either now or in the very near future. This week, we had a very quiet minor release of GJDoc, the GNU Classpath equivalent to javadoc. 0.7.9 includes a few changes that were previously only available in CVS, but the main one is a small fix that allows Classpath 0.97.1 documentation to be built. Our minor .1 release for 0.97 fixed a bug where the JSR166 code was not being included in the documentation build. With this fixed, it turns out gjdoc would no longer build the documentation as java.util.concurrent.TimeUnit is a rather complicated enumeration that our hacks can’t bypass. Michael Koch, in packaging GJDoc for Debian, was kind enough to point out that having the current release of GJDoc not being able to build documentation for the current release of Classpath was a bad thing. A quick release fixed this by pushing out the fix I made for this issue back in March. Of course, you can now use javadoc for IcedTea/OpenJDK to build the documentation instead; with another Free JDK about, there’s no need to just rely on GJDoc.

I do wonder what the long term future for GJDoc should be. It only works with GNU Classpath at present through a nasty bunch of hacks which cause the parser to skip chunks of the input. It really needs a major cleanup and to be made to work properly with 1.5 code. Thomas Fitzsimmons suggested we should merge it into the GNU Classpath codebase which seems a good idea, as it means we don’t run into this same revision hole we just did. However, it is worth maintaining GJDoc at all? For me, the main features it has over the OpenJDK javadoc are in speed and the look of the output. A key feature is also that it it plays nicer with Free Software i.e. it includes an option to include the source code with syntax highlighting. You can see the output for Classpath 0.97 online.

JikesRVM is also stepping up for a new release, 2.9.3, and this will be the first to showcase the new Classpath support for a non-copying unsynchronised StringBuilder. This is designed for local method usage where the builder will be converted to an immutable String object rather than leaving the method. As a result, I’ve been rushing to get it in a releasable state, as I know there’s a nasty bug lurking in the older patches JikesRVM has been using recently. I managed to do this today after we fixed a build issue. It seems the javah in OpenJDK6 outputs differently named header files to those JikesRVM implicitly depends on. We fixed this by making this dependency explicit as it should be, but perhaps this also uncovered an OpenJDK6 bug. I’m not sure where we should be filing these yet, so I just posted to jdk6-dev.

It’s also nice to hear that Ubuntu has just shipped with IcedTea6 included. Fedora 9 will also ship early next month (May 13th) with similar support and an OpenSUSE build is in the works. It’s nice to see Java support making it into the mainstream, thanks to Sun’s recent moves to make their JDK Free Software. On the less positive side, it seems that Gentoo won’t see support for IcedTea6 anytime soon. The Java Gentoo developers seem to be on a strange mission to support only the proprietary Java solutions (pretty much an inverse of what Fedora, Ubuntu and Debian do). In porting my IcedTea6 ebuild from the Libre Java overlay to their own overlays, they seem to have decided to drop support for GCJ… I’m not even going to go into how dumb this action is, as I could be here a while. Suffice to say, I don’t see how IcedTea6 can be bootstrapped without GCJ, let alone how they expect to then build it on architectures like PPC, PPC64 and ARM, as we’ve seen happen on the OpenJDK distro mailing list. It seems a very odd move for a distribution supposedly built on compiling things from source…

Over the last week, I’ve been getting Gentoo and Free Java up and running on my new x86_64 box, a process which has culminated in the creation of my own overlay:

http://fuseyism.com/hg/libre_java_overlay

For those unfamiliar with Gentoo, an overlay is an additional set of packages (known in Gentoo as ebuilds, as for a source-based distribution the packages are essentially build scripts) which can be placed over the top of the main system tree to provide newer/better versions of existing builds and completely new ones too.

The Libre Java overlay includes a build for GCJ 4.3 (adapted from the one for an alpha snapshot in the java-gcj-overlay) and one for IcedTea6. Unfortunately, Gentoo’s Java support seems incredibly broken — the main stable and experimental (~) distributions don’t include OpenJDK or IcedTea, and the stable versions of GNU Classpath and VMs like CACAO and JamVM are ancient. GNU Classpath is still on 0.90, which is older than the one in Debian stable. It also tries to pull in the proprietary JDK by default; I recommend Free Java Gentoo users add:

dev-java/sun-jdk
dev-java/ibm-jdk
dev-java/jrockit
dev-java/diablo
dev-java/sun-jre-bin
dev-java/blackdown-jdk

to package.mask to avoid accidentally installing proprietary software on their machines. Unfortunately, stable versions of portage have yet to honour any license scheming, although it is in the unstable version. If you use Gentoo, feel free to try out the ebuilds from my overlay and give feedback. To use it, just get Mercurial (emerge mercurial), clone the repository:

hg clone http://fuseyism.com/hg/libre_java_overlay

and then add the following to /etc/make.conf:

PORTDIR_OVERLAY=<location you downloaded libre_java_overlay to>

The build process for IcedTea6 is fully documented on the IcedTea wiki.

Having just read Andrew Cowie’s recent blog, I wanted to comment but couldn’t find an option to do so there. So here it comes here on my blog instead…

Simply put, OpenJDK is so named because it’s a FOSS version of Sun’s JDK the implementation, not Java, which is the specification. Just because OpenJDK is the reference implementation doesn’t mean it is the specification as well. The equivalent would be calling Tomcat OpenServlet (it being the reference servlet implementation). This also reflects on the comments about the HTTP server being in com.sun. This is because it is part of Sun’s implementation and not part of the Java specification. To become part of the specification requires a JSR and interaction with the JCP which are distinct and separate from OpenJDK. That’s the process that would result in java.net.httpserver (or, more likely, javax.net.httpserver because it’s not an essential part of the core).

I hope that clears things up. I’m really happy OpenJDK has found an interesting alternate use that clearly demonstrates the benefits of the FOSS implementation over the proprietary one, and thanks for blogging on this. Now you should go build IcedTea…

I read Mario and Roman’s posts this morning and they inspired me to post too, after realising that there was a lot of stuff that’s been going on that I also hadn’t blogged about. Firstly, Google Summer of Code closed its doors to student applications on Monday (well Tuesday really, here in Europe) and we were rather disappointed to find only two applications for GNU Classpath, both for java.util.Scanner. This is a real pity, as I think we had some really good ideas on the list (and even more interesting ones were left to one side after AICAS didn’t get in as a mentoring organisation).

I think students picked Scanner because it’s used on many undergraduate courses these days (something of which I was blissfully unaware, as it’s years since I did any introductory Java course or read an introductory book). Unfortunately, the future of such an idea is really dubious, as I explained to our first applicant online, as there is already an implementation (no idea how good or complete) by a student of Christian Thalinger (twisti) which we hope to get into the codebase, once the legalities are sorted out. Equally, we are looking at using BrandWeg to get the OpenJDK version; this has only really ground to a halt because I found we’d need to either update our regex implementation or also bring in the OpenJDK one and I simply haven’t had time. Again, BrandWeg was on the ideas list, but no takers

Personally, I’ve mainly been looking at IcedTea recently, in preparation for the OpenJDK challenge work. I haven’t really blogged on the details of this yet, but my first port of call will be to take an OpenJDK/IcedTea build and attempt to get the class library from that to work with one of our Free GNU Classpath VMs. Rather than trying to build the Sun interface into that VM, I want to use that process to figure out the best way to create a more well-documented VM interface including support for VMs that don’t want to go the native route for the VM interface. I intend this to be an interactive process so I’ll be posting results and hoping for feedback as we go along. As the OpenJDK challenge infrastructure gets sorted, I expect this will take place under the auspices of an OpenJDK project. I’ll be tagging appropriate blogs with the ‘VM interface’ category so feel free to track them.

One question that does spring to mind is whether the challenge projects are intended to work with OpenJDK or OpenJDK6. IcedTea work has pretty much shifted to OpenJDK6 (in the form of IcedTea6) with good reason; distros want to ship a stable Free equivalent to JDK6, not an early alpha of JDK7 (which doesn’t yet even have a JSR attached to it). Ideally, I think we should maintain both, as the IcedTea porting process seemed to suggest the differences weren’t too major. But feedback here would be welcomed. I’d also like to make the new VM work easy for others to test, so hopefully some integration with IcedTea will be possible there too. I’m very impressed with IcedTea so far, especially Gary’s zero port (as my previous blogs hopefully illustrate). There are some niggles, but lots of eyes and people testing it in different environments will fix these. It’s great to have OpenJDK on PPC64 for one thing!

To close, I notice that people are moving around in the Free Java world (as my reference to Mario’s title in mine hopefully indicates). First, Tom Marble left Sun earlier this year, and now we find that Dalibor has successfully stepped into his (hopefully clean) shoes. To me, there doesn’t seem to be a more appropriate replacement, though it does make his governance board position interesting… Mario has also now moved to AICAS, so it seems like most people are getting new jobs and different roles in the new Free Java world brought about by OpenJDK. Things will change for me as well soon, as I’m due to finish my PhD here in October (well the funding runs out at least, which means I need some alternate source of cash at any rate). So it will be interesting to see where I am in a year from now too…

Some good news on Wednesday:

IcedTea is served: openjdk/control/build/linux-i586

$ java -version
java version “1.6.0″
IcedTea Runtime Environment (build 1.6.0-b08)
OpenJDK Client VM (build 1.6.0-b08, mixed mode)

IcedTea is served: openjdk/control/build/linux-ppc64

$ java -version
java version “1.6.0″
IcedTea Runtime Environment (build 1.6.0-b08)
OpenJDK 64-Bit Core VM (build 1.6.0-b08, interpreted mode)

As an addendum to my previous blog, Debian Etch needs a backported Freetype to be able to build IcedTea. I’ve finally made my x86 backport available.

As those who’ve had the unfortunate luck of being in our IRC channel over the past few days will know, I’ve been trying to build IcedTea6 on our Debian etch server again. The good news is it looks like I may have succeeded this time, with some help from Christian Thalinger (twisti) and Gary Benson (gbenson).

Basically most of the tools that come with etch will be useless in your task. The versions of Kaffe, GCJ and GNU Classpath+JamVM that come with it don’t support the 1.5 language extensions. To add insult to injury, because the gcj backport used by Fedora is ‘4.1′, IcedTea won’t scream at you for a default ./configure; make. Instead, the OpenJDK sanity check will tell you that you don’t have a 1.6 VM to bootstrap with (although you only actually need a 1.5 one…). This is because IcedTea will symlink bootstrap/jdk1.6.0/bin/java to the gij that is part of etch, which reports itself as 1.4. Similarly, the jar file it picks up is a pre-generics version of Classpath that can’t be used even with a VM that claims to be 1.5.

So you need to build your own Classpath Java stack before proceeding with trying out IcedTea6. This machine is used to do my regression testing for Classpath so I already had an install of 0.97.1, but it’s simple enough to get a copy of GNU Classpath and a compatible VM if you don’t. You CAN use what is installed with etch to build this. The simplest way to do that is to install the java-gcj-compat-dev package which should give you a native version of ecj.

Using this, you can download Classpath 0.97 or any prior version up to 0.95 (the first to include the code merged from the generics branch). ./configure; make; make install should work, but you probably want to use --prefix to install it in a local directory rather than /usr/local/classpath. --disable-plugin is something I also usually add to avoid having to had the Mozilla headers.

Once installed, you need to add a 1.5 VM that works with this. CACAO (from the Mercurial repository), JamVM or the new Kaffe release should work. I used CACAO. You can then configure IcedTea6 by pointing it at the new install. Assuming $CLASSPATH is where you installed everything:


./configure --with-java=$CLASSPATH/bin/java --with-libgcj-jar=$CLASSPATH/share/classpath/glibj.zip --with-jar=$CLASSPATH/bin/gjar --with-rmic=$CLASSPATH/bin/grmic --with-javah=$CLASSPATH/bin/gjavah


Before building, you also need to patch glibc (thanks to twisti for this tip). Don’t worry! It’s not too scary, just a simple change to a shell script, to make it the same as in more recent versions. On x86, the change is in /usr/lib/libc.so. The last line should read:


GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED (/lib/ld-linux.so.2 ) )


If you’re on x86_64 or ppc64 (or any 64-bit platform i guess), you need to patch /usr/lib64/libc.so:


GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld64.so.1 )


That done, you should be able to run make and hopefully reach the message that IcedTea is served. YMMV of course, so let me know how you get on. This was quite a bit easier than when I last remember trying, so hats off to the IcedTea folks for all their hard work. Next stop, Solaris…