GNU Classpath, essential libraries for java, is a project to create free core class libraries for use with runtimes, compilers and tools for the java programming language.

The GNU Classpath developer snapshot releases are not directly aimed at the end user but are meant to be integrated into larger development platforms. For example JamVM, CACAO and Kaffe can make use of an installed copy of GNU Classpath 0.97.2, while GCC (gcj) will use the developer snapshots as a base for future versions. For more projects based on GNU Classpath, see http://www.gnu.org/software/classpath/stories.html

This is the second of a new series of bugfix releases that follow a major (0.x) release. A 0.x.y release will only contain minor bug fixes. It will not cause major changes in the functionality of GNU Classpath, either for better or for worse.

With this bugfix release, the following issues have been resolved:

* Include headers in the release tarball.
* Allow the building of tools to be optional.
* Only check for a Java compiler when required.
* Allow VMOperatingSystemMXBeanImpl to compile on Solaris.
* Documentation typo fixes
* Fix memory leak in native/jni/classpath/jcl.c
* Web page updates (PR classpath/22883)
* Fixes to pass the JSR166 TCK
* Use awk to construct the classlist on building
* Fix deadlock in Logger (PR classpath/35974)
* Fix regression in java.lang.String (PR classpath/35482)
* Allow Classpath tools to handle @file options.
* Allow parseInt to handle a + prefix correctly.
* Remove use of 1.5 language constructs in the VM layer.

From the 0.95 release, we switched fully towards the 1.5 generics work that we previously released separately as classpath-generics. All this work is now fully integrated in the main release and various runtimes (GCJ, CACAO, JamVM, JikesRVM etc) have been extended to take advantage of the new generics, annotations and enumeration support in the core library. As a consequence, only 1.5 capable compilers (currently the Eclipse Compiler for Java (ecj) and Sun’s javac) may be used to build Classpath.

The GNU Classpath developers site (http://developer.classpath.org/) provides detailed information on how to start with helping the GNU Classpath project and gives an overview of the core class library packages currently provided.

For each snapshot release generated documentation is provided through the GNU Classpath Tools gjdoc project, which will become part of GNU Classpath itself with the release of 0.98. A documentation generation framework for java source files used by the GNU project. Full documentation on the currently implemented packages and classes can be found at: http://developer.classpath.org/doc/ We are looking into how to extend the documentation experience in the future. Please contact the mailinglist if you would like to help with this effort.

For more information about the project see also:

GNU Classpath home page: http://www.gnu.org/software/classpath/
Developer information (wiki): http://developer.classpath.org/
Full class documentation: http://developer.classpath.org/doc/
GNU Classpath hackers: http://planet.classpath.org/
Autobuilder, current build status, build snapshots:
http://builder.classpath.org/

Application test pages (wiki):
http://developer.classpath.org/mediation/Applets
http://developer.classpath.org/mediation/FreeAWTTestApps
http://developer.classpath.org/mediation/FreeSwingTestApps
http://developer.classpath.org/mediation/FreeSWTTestApps
GNU Classpath hacking with Eclipse (wiki):
http://developer.classpath.org/mediation/ClasspathHackingWithEclipse

GNU Classpath promotion banners:
http://developer.classpath.org/mediation/ClasspathBanners

GNU Classpath 0.97.2 is available from ftp://ftp.gnu.org/pub/gnu/classpath/, one of the ftp.gnu.org mirrors (http://www.gnu.org/order/ftp.html) or the Classpath continuous integration system (http://builder.classpath.org/dist)

File: classpath-0.97.2.tar.gz
MD5sum: 6a35347901ace03c31cc49751b338f31
SHA1sum: 627e9781f9bb744b1a70e4aaff88d2d0440cbf1f

The following people helped fix bugs in Classpath 0.97.1:

Andrew John Hughes, Michael Koch, Jim Meyering, Robert Schuster, Mario Torre, Tom Tromey, Ralf Wildenhues

The following people helped with the release of Classpath 0.97 and/or 0.97.1:

Luciano Chavez, Thomas Fitzsimmons, Bernhard Fischer, Jeroen Frijters, Stefan Huehner, Andrew John Hughes, Jakub Jelinek, Ito Kazumitsu, Roman Kennke, Alexandre Oliva, Petteri Raety, Ian Rogers, Robert Schuster, Leen Toelen, Mario Torre, Dalibor Topic, Tom Tromey, David Walluck, Mark Wielaard and Ralf Wildenhues.

We would also like to thank the numerous bug reporters and testers! In addition, we’d like to extend our thanks to all those who’ve contributed over the years and have helped in building a thriving and friendly community around the GNU Classpath project.

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.

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.

CPStringBuilder instead optimises for the frequent cases where a StringBuilder is created, used to build a String and then discarded after toString() is called. It does so by handing a reference to the character array to the new String object on creation. Once this is done, it flags internally that the array has been used and creates a new one if any further writes are requested. Thus, using CPStringBuilder should always be one copy more efficient than using StringBuilder or StringBuffer (possibly even creating just a single array if the final string is within the initial capacity) and we now use it internally when the builder does not need to be thread-safe.

The problem with implementing this is that it requires passing the array to the constructor of the String object. There is no such constructor in the public API for String, although Classpath has had a package-private one for sometime (GCJ and String itself already use it). But how do we access this from the gnu.java.lang package? Our current method is to use reflection, and thus we have VMCPStringBuilder so VMs can optimise this natively.

When looking through OpenJDK for the VM project, I noticed that they have a rather interesting solution to this. This is encapsulated in sun.misc.SharedSecrets. This class provides access to instances of a number of public interfaces, such as sun.misc.JavaLangAccess. The actual implementations are provided as inner classes in the appropriate package e.g. java.lang, where it has access to the private and package-private variables and methods within. For instance, JavaLangAccess provides access to the constant pool for a particular class.

The only noticeable negative side effect of this is that any external class may also call these methods. For example:

import sun.misc.SharedSecrets;

public class TestSecrets
{
  public static void main(String[] args)
  {
    System.out.println(SharedSecrets.getJavaLangAccess().getConstantPool(String.class));
  }
}

whereas the equivalent for GNU Classpath:

import gnu.java.lang.VMCPStringBuilder;

public class TestCPSecrets
{
  public static void main(String[] args)
  {
    System.out.println(VMCPStringBuilder.toString(new char[]{'H','e','l','l','o'},0,5));
  }
}

fails to compile because VMCPStringBuilder is package-private (although the equivalent is possible by using CPStringBuilder in this case). As a result, it becomes slightly more important to ensure that the possible damage from using these classes is limited.

That said, this may be an interesting and more efficient method for us to look into for GNU Classpath.

The latter I feel is very important and, as I currently work in a University, it’s a topic close to my heart. Access to source code is an invaluable learning aid. The few pieces of source code our students see, that they haven’t developed with their own hands, are throughly mothballed pieces of code which barely hang together by a string, having being developed by one academic long ago and then passed on like some hand-me-down. They certainly aren’t examples of good coding, but you won’t always find this in Free Software either. What you will find is code that has been used by hundreds if not thousands of users. Code which has been built on numerous platforms and maintained by GNU/Linux distributions. Code which has stood the test of time and experience, even if it still comes out dirty at the end. By contrast, the examples most students see are reused year after year with little to no change to the code. One of our lecturers is currently only distributing the code the students need as binary simply because the code itself is so ugly and hairy he doesn’t want them to use it as an example. The advent of the OpenJDK project will help, because it should mean that the software on the desktops of Free Software users more and more utilises Java. Why is this important? Because the majority of students are taught Java first and foremost. Most of our students never use C throughout their undergraduate life. So examples of big bodies of Java code are what’s needed and the OpenJDK is a great contribution in this respect, as is GNU Classpath — they both provide samples of the good, the bad and the ugly.

The other important point about Free Software in Education is the ‘get them while they’re young’ theory, which rms likened to addicting children to drugs. He seems to like harsh metaphors, but this one I feel is not too overboard. Certainly, proprietary software vendors provide school and university students with cut-down or gratis copies of their wares. The students get used to this software and start to use it. In many cases, they are effectively forced to, as part of their studies. When they then step out into the big wide world, this is all they know. And our teachers and lecturers, far from promoting sharing and education as they should, are helping this addiction process, even if it’s simply by distributing a Word document to students or using that as the format for a handin. I’ve had to repeatedly mail back our university admin staff of late to obtain the minutes to meetings in a format other than the Word document they keep dropping in my inbox. One would hope they would start to take the hint…

For the finale of the talk, we were lucky enough to be visited by St. IGNUcius of the Church of Emacs. rms then took questions from the audience for well over an hour. He has a very admirable way of doing this; he clearly takes in every word being said, and you can hear the response before it comes when someone mentions ‘open source’ rather than ‘free software’ or some other faux pax, which they really should have known better than to utter, given the preceding two hours talk. I’m really surprised rms didn’t get more exsasperated than he did at some of them. I guess he must be used to it by now. He certainly seems to have a clear well-thought out answer for everything.

For those who couldn’t make the talk, I recorded it in full (with questions) and, with the help of Tim Dobson from the Manchester Free Software group, have made this available on-line. Where possible, we’d prefer you obtain the video from the torrent to reduce bandwidth load on those kind enough to host this. You can find the appropriate links on my website. If anyone would like to provide a further HTTP mirror of this, please get in touch. You can also help the Free Software community by helping to seed this via BitTorrent — this will help others get a copy

‘Free Software in Ethics and Practice’ - speaker: Richard Stallman

Thursday 1st May, 2008 - Talk starts at 6:45pm (ends approx. 8:30pm) with refreshments from 6:15pm.

Venue: Room D1, Renold Building, University of Manchester, Sackville Street, Manchester M1 3BB

http://manchester.fsuk.org/blog/

I’ll be there, fingers cross, and hopefully I’ll also be able to record the event.

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…

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.

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