GNU/Andrew’s Blog

We are proud to announce the release of GNU Classpath 0.97.2, the second bugfix release for GNU Classpath 0.97.

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.

One interesting issue when writing a runtime class library for Java is how to give implementation packages, whether they be in gnu.* or com.sun.*, specialised access to the core runtime classes like those in java.lang. We ran across this problem again recently with GNU Classpath when trying to write CPStringBuilder. This is a StringBuilder variant that differs in how it utilises its internal character array. StringBuffer and StringBuilder both maintain their own character array throughout their life, creating a new larger one and copying when appropriate. When toString() or substring(int,int) is called, the new String object is given a copy of the array.

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.

(more…)

So I went to the rms talk last Thursday and throughly enjoyed it. This was the second time I’d seen him speak, and can certainly recommend it to others. As others have remarked, he is quite entertaining to listen to and the way he upholds and adheres to his values is worthy of admiration. The last time I saw him speak (maybe three or four years ago in Sheffield), it was on the subject of software patents. This time round, I was treated to a more general FOSS talk, which touched on well-known topics such as the history of GNU, the whole GNU/Linux debacle and truly Free distros along with DRM. rms also made specific mention of commercial Free Software (a common point of confusion for many) and of Free Software in education.

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

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.

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…

It’s that time of year again! This time, I’ll hopefully be mentoring some students instead, especially after my OpenJDK Challenge proposal was accepted.

If you’re a prospective student for SoC 2008 and would like to work on Free Java, then please come and join us on either:

• GNU Classpath (listed under the GNU Project mentoring organisation)
• JikesRVM

Want to find out more? Then mail classpath@gnu.org or hop into #classpath on FreeNode IRC (same network as #gsoc this year).

It was FOSDEM this weekend, and once again the Free Java hackers (now including many Sun employees) met up in Brussels to discuss the past, the present and the future. We had an extremely good turnout, better than last year (the only other year I’ve attended so far) and with nearly all the Free Java people there (notably MIA were Tom Tromey and Michael Koch). Tom Marble did a great job of encouraging everyone to give a talk, so, unlike last year, I think we heard from everyone working in the Free Java space. It certainly left me with plenty to think about.

Just before leaving for FOSDEM, I got 0.97 out of the door (or tried to — there were problems doing the upload again, but this should be sorted now for next time). In hindsight, this was a bad idea as I was then very tired for most of the trip and, in conjunction with having a bit of a cold, this meant I didn’t enjoy the weekend as much as I’d have liked. Anyway, the main point about the release was that it was supposed to represent that GNU Classpath was still around, even if not going strong, and not merely a dead carcass for people to pick the bones of. However, FOSDEM made me realise that we may be seeing the end of GNU Classpath sooner than I thought. With the planned BrandWeg hacking session on the Friday, that was initially going to be my main focus of the weekend, but from the talks it seems most people are further along the road to OpenJDK than I thought. Maybe the BrandWeg idea is coming about six months too late and we should have gone there around the same as IcedTea. As is, CACAO, JNode and IKVM.net are already using OpenJDK, and JamVM, Kaffe and JikesRVM all have their sights on going there too. There was unfortunately no real discussion of GCJ, so it may just be that, with RedHat’s focus on IcedTea, there will be no further development there at all, which is a shame. Overall, FOSDEM gave me the impression that our Free Java community now want OpenJDK and have grown out of their ‘toy’, GNU Classpath. I’d be interested to know if others think this is true too.

The most interesting talks for me, however, were those at the end where the TCK and the JCP was discussed. As Dalibor has mentioned in the past, I couldn’t help thinking we might have targeted the wrong opponent. While it’s nice to have the more stable, mature codebase of OpenJDK out in the open, when all is said and done, it’s just another implementation (and in some ways a competitor for Classpath, at least in terms of the attention of developers). The fundamental problem is the JCP, which still largely turns out proprietary TCKs and RIs (Doug Lea’s JSR166 being the notable exception to the norm). In the long term, a truly Free Java platform is not just about implementations but about the specification and an open process surrounding that. This is perhaps what has been the barrier to people getting involved in OpenJDK; because OpenJDK is largely an amalgam of reference implementations of JSRs, all FOSS hackers can do outside these JSRs is bugfixes which, while necessary, don’t set their hearts on fire. A true Free Java community can only really work with participation in open discussions that determine its future and with a Free Software TCK. I think Andrew Haley explained the benefits of the latter very eloquently in his talk, where he demonstrated how a number of annoying bugs in our code could have been spotted much earlier and easier had the TCK been available. Can we not separate the test suite from the certification process in some way, such that the tests can be developed in the open (and can thus be more readily trusted) and used by more than just licensees? Anyone want to join the JCP and make an impact?

In more technical news, not only is Classpath 0.97 out, but I successfully compiled it on Nevada (via a SunRay connection) this afternoon…

Well, this year is trotting along quite nicely so far and there have already been some quite interesting developments. Plus it’ll soon be time for FOSDEM again! Probably the most major thing for me is the continued development of OpenJDK-related projects. After a discussion with Dalibor via IRC a couple of weeks ago, we launched a new project called BrandWeg. This is effectively the inverse of IcedTea; we take Classpath and try to patch its holes using OpenJDK as the plaster.

It’s notably different as a repository in that it contains no source code, only patches. Instead, the build downloads Classpath from CVS or a tarball, and then the requisite OpenJDK sources from either Mercurial or a tarball. At the moment, it just merges in the jaxws stack, as this is completely unimplemented in Classpath and separated in the OpenJDK. As such, it seems like it should be easy to add this in by merely putting the sources into external and linking it into the build system. Unfortunately, the code may be in different repositories but they are by no means orthogonal unfortunately. Trying to build with jaxws in there makes the build scream for mercy — among the errors, there are ones looking for a HTTP provider in com.sun (presumably tucked away in the main JDK sources) and some evil direct use of the com.sun.org.apache XML providers. So it’ll need a bit of patching before we have our first BrandWeg build.

I’ve also returned to a little work on IcePick, after doko has started trying to build native GCJ binaries from its output. Together, we found and patched a few bugs and I’ve finally implemented better wrappers for the tools. Notably, these don’t depend on the -Xbootclasspath option which I picked up from the Classpath tools but which doesn’t work with gcj, and they also handle the -J options. The wrapper is now a little bit of C code that is compiled with different defines depending on the required tool.

Feel free to check these and let me know what you think.

Finally, the last bit of news concerns OpenJDK again. Through the last year or so that we’ve been working with the new OpenJDK development, our main contact with Sun has been through Tom Marble. He’s proved to be a great guy to work with, always patient enough to listen to all our quibbles and our ongoing complaints and whines about the glacial progress of the OpenJDK community development. So, it’s with some sadness that we found out this week that he’ll be leaving Sun soon and heading off for pastures new. I hope he appreciates how much of an asset he has been to us GNU Classpath developers in our trips into the unknown world of the OpenJDK and I’d like to join with the rest of the Free Java community in thanking him for his tireless work and wishing him all the best in the future. Thanks Tom!

Well it’s now 2008 (unless you’re in the US of course) and traditionally a time to reflect upon the year just gone. Well, it’s certainly been one of movement and change in the GNU Classpath community, if also one of very little code hacking. Of course, the biggest event of the year was the release of the OpenJDK source code in May; about 95% of the JDK source code base was made available under the GPLv2, the rest both then and now being filled by binary blobs, which are slowly decreasing in number.

However, back in January 2007, we were still waiting for this to happen. As I recall, we’d just (gone through the generics merge, migrating the contents of the branch on to the main tree and over the Christmas period I added quite a lot of 1.6 code. Sun’s javac compiler was open-sourced however, as part of the November announcement, and we soon had support in GNU Classpath for building with it.

In February, GNU Classpath was again at FOSDEM and I finally attended after missing out on the last two years. It was good fun and notable for our collaboration both with the DevJam folks and the OpenJDK community (AKA Sun). Everything was very much still ifs and buts however, because I don’t think anyone knew what would really happen when the floodgates opened and the JDK was released. Of course, GNU Classpath will again be at FOSDEM this year, and apparently with even closer collaboration with OpenJDK — try and even spot a mention of GNU Classpath on those pages… Hopefully, I’ll be there again too.

The year only saw two Classpath releases, which is sort of representative of its ongoing decline I guess. 0.95 was released shortly after FOSDEM in April, a delayed and very necessary release which include the generics move and the other stuff I mention above. Getting a GNU Classpath release out the door has become more and more of a struggle over this year and, in a way, has become synonymous with a pregnant mother giving birth, as a team of developers stand round screaming ‘push’ until eventually the release emerges. Our release of 0.96 in October certainly felt like that to me anyway. On that note, congratulations to both Michael Koch and Roman Kennke who both (or should I say, their respective partners) had children this year.

May of course saw the release of the OpenJDK source code and the inevitable hordes jumping on and pulling it about took place with the same speed and haste we saw on the release of javac. This has eventually surfaced in the form of IcedTea from a number of GNU Classpath/RedHat folks, a build framework for the OpenJDK which, most importantly, serves it without the need for proprietary code (given that the current OpenJDK build has no real advantage over a proprietary JDK drop unless you want to tinker). This was produced by splicing in bits of GNU Classpath code. It’s a whole deal more easier to use than plain old OpenJDK but still not a walk in the park. This is especially true since Sun split up the build process and made parts of it depend on Ant…

It’s quite sad to say, but OpenJDK is still not what we all hope it will be. Thankfully, live Mercurial repositories are now available as of December, but there are still too many walls, as I mentioned before. It’s like the JDK was something that popped out of a little black box, but now someone has taken the lid off the box so you can see the little worker ants running around inside and making it all happen. But there’s not yet anyway to get inside the box ourselves. New ants need to be able to join in the fun. We’ve already seen one of the goals I mentioned in August realised (the open repositories), and hopefully more will change in 2008. Sun’s innovation awards are both a realisation of this problem (common to both OpenJDK and many of its other open source projects, which still have a predominantly Sun ethos) and hopefully its saviour.

It smells a little like Google’s Summer of Code and indeed Tom Marble was asking myself and Mario about this on IRC. This year of course saw me tackling JikesRVM for GSoC, trying to implement the VM-level management extensions. A lot of this work was done, and following GSoC, I was made a member of the JikesRVM team. However, the patches still haven’t gone in to the mainline, due to a combination of the release process (some of these are likely to be destablising) and finding time myself to test the stuff on the main branch. This hasn’t been helped by a re-emerging problem with building JikesRVM using Classpath; this same problem plagued my initial month or so on the project when I discovered it seemed to rely on proprietary software to work…

So altogether it’s been an interesting year. Not only have I worked on both the old (continuing with GNU Classpath and also pushing out a release of GJDoc) and the new (launching the IcePick project to build the OpenJDK tools separately) over the last year, but I’ve also sadly seen the community enter something of a demise as people start to move on to other things, especially IcedTea and OpenJDK. What will 2008 hold? Maybe I’ll find myself working on OpenJDK too…

One of the things I’m currently working on is getting Classpath to a state where the java.lang.management stuff I’ve worked on becomes useful i.e. where we can attach to a VM either locally or remotely and get pretty graphs of things like memory usage via JConsole.

I’m tracking this via a couple of meta bugs. PR34277 represents our final goal of being able to monitor Classpath VMs and use Classpath to monitor other VMs, while PR34078 is looking at simply getting JConsole up and running on GNU Classpath. I’ve had some progress with this today. I’ve closed three bugs (two of them Swing/AWT ones which I’m quite chuffed about) and finally got some visible progress:

So far so good. The menus don’t work though (PR34581) and there’s also a problem once you click Connect (PR34582). The latter looks easy enough to solve (we just need to be checking for null!) and the menu thing is more of an annoyance than a blocker (the keyboard shortcuts on the menu items do work). However, I feel there is still a lot more to do before it works.