This is the list of open GNU Classpath implementation tasks. Once you start working on a task, move it to the ClasspathCurrentTopics.


Swing in general still has missing methods and classes. It would be nice to have a Swing plaf which uses Gtk underneath, so that it adapts to the Gtk theme.

AWT Peers

We have AWT peers (interface to the native GUI) using the new Cairo library ( These need improvement. Although this might need to wait until Cairo is more stable.

Currently our AWT peers are built on GTK. This doesn't mean we don't want to support other toolkits and/or platforms. KDE, OS X, Windows, etc. This is a rather large task. Requires knowledge of the target platform (of course) and JNI.


Arabic shaping

Arabic text is currently written in correct order (right-to-left) but the characters need joining. This job is to be done by FreetypeGlyphvector. For details on the algorithm, see Chapter 8.2 of the Unicode standard. ( This isn't that hard to do, but certain character pairs will end up represented as one glyph. The glyphvector impl needs some small modifications to handle this. (TextLayout *should* be able to handle this already, however this is not well tested).

Devanagari & friends

Similarily, the south-Asian scripts require some more work to be done in order to convert to glyphs. This is detailed in chapter 9 of the standard. ( It's a bit more work than the Arabic case, but mostly it'd be helpful if someone who knows the language did this.


Finish TextLayout - not too much work left here, but you can see the methods in the JAPI scores. More testing and bug-hunting is of course welcome too. The class is now complete API-wise and the more important methods are actively tested by using it in javax.swing.text styled text rendering for caret positioning etc. However, this class certainly needs some more attention wrt strange languages (vertical, arabic, etc).


The awt.image code needs to be checked and tested closely. There's a lot of bugs in there and some stuff which is plain wrong. (E.g. calls to ColorSpace methods with bad parameters).


Make CairoSurface extend Raster and implement some interface for BufferedImage to get Cairo implementations of Raster. So that creating an ARGB BufferedImage will create a surface Cairo can draw directly and also draw to. Other BufferedImage types can keep a copy of themselves as this kind of raster and copy that data back to the original raster when the user does a BufferedImage.getData(). BufferedImageGraphics can then be dropped.


We need a headless toolkit which getDefaultToolkit() can return. (which can do the job of throwing the HeadlessExceptions, not as now in the AWT code). At least right now I've got plans for a Cairo +Freetype-based one, which'll allow us to reuse existing code. This will require:



The classes like AccessibleJTableHeader, AccessibleJComboBox and many other Accessibles are still not complete. The task would be encouraged by the fact, that the java-access-bridge ( can work with our Swing and our CORBA communicates with ORBit without visible problems.



We can never have enough plugins! If anyone wants there's all kinds of obscure formats left to support. TIFF, PICT, Targa, ICO, CUR, Sunraster, XBM, XPM, PCX, Amiga IFF. Whatever you feel like (some of these are really simple).

If you're a newbie and can't be bothered to learn the whole IIO framework just to contribute a simple plugin, if you want, you can always just contribute something along the lines of:

and someone more experienced around here can wrap that with the necessary plugin code.

There's a couple of plugins in the BSD-licensed part of JAI. Maybe include some of these.

Composite Contexts

Implement some CompositeContexts for Porter/Duff operators on raster images. This would be useful for supporting 2D graphics. See java.awt.AlphaComposite and its createContext method.

Miscellaneous Providers

Various library APIs simply forward to underlying providers. In some cases Classpath does not yet have a provider.


We currently have memory, file and GConf providers. It would be nice if our file-based provider were compatible with the JDK.



This is the provider that should provide audio input/output for performance/capture. Providers for ALSA, OSS, and perhaps GStreamer and Jack would be useful.


There are several good C libraries for reading/writing audio files (libsndfile, for instance). However, it's not clear how one might hook them together with the SPI API, which needs to work with Input/OuputStreams. It may be easier to develop these in pure java. Start with aiff and wav which are the most common form used in java applets. There are some good third party SPI providers for FLAC and OGG. Should these be imported?


Same as above. There are lots of good C libraries for this, but do they provide the necessary APIs? Somebody needs to investigate this.


The default Synthesizer should be a GM compatible MIDI device. It would also be best if it used ALSA or OSS for output instead of requiring a special audio server (like jack, which today is only really used for special audio production apps, not general purpose performance). fluidsynth could provide the engine if we could find a distributable GM soundfont.

We also don't have a Sequencer device yet. Something using ALSA might be OK. Pure Java may also work well enough.


Write or adapt IDL to java compiler

Despite it is possible to work without IDL compiler (current tests are written in this way), this tool is really needed by the CORBA developers. As Classpath should be compatible with the Sun's implementation, it seems accepting output of the Sun idlj. However the code of that compiler is proprietary, it would be better to adapt one of the Free implementations.

Continue CORBA implementation

Despite CORBA implementation in the Classpath project is now a working prototype, a number of tasks are still available. If you are not a CORBA expert, you should be ready to learn by reading the OMG specifications (see and probably by writing some relatively simple classes.


Continue RMI implementation

The Remote Method Invocation code is not fully complete, especially the remote class loading and some security features. Difficulty: Intermediate, requires knowledge of RMI .

Write RMI tests

Despite the most of RMI classes are complete and seem working, this package lacks the necessary tests. The absence of tests slows the optimizations and other development, raising danger of degradation. It is necessary to have the RMI test suite (either as part of Mauve or standalone).


More character sets for Java NIO

A list of the supporter character sets in the JDK is here: We've got a big number, but still need more. (sources in gnu/java/nio/charset) Difficulty from easy to intermediate depending on the charset.

Rewrite Java NIO Socket implementation

PR classpath/28619 The current implementation of GNU Classpath' socket channels is based upon A rewritten implementation would directly use the operating system's socket library instead and make heavy use of the Java NIO buffers to enhance performance.

Additionally the current implementation cannot deal with non-blocking IO which could be fixed then.


Make Mauve an Application

On some environments, it is not possible to run shell scripts because there is no shell. Make the Mauve test suite a self-contained application (one big JAR file).

Write Mauve Tests

Write more Mauve tests

Robot based Mauve tests for javax.swing.JTree and javax.swing.JTable

During the history of the project, these two complex components have several times suffered from significant regressions, being "revived" to the working state only after considerable amount of time. This proves that the current level of testing is not sufficient.

Using java.awt.Robot which can simulate both keystrokes and mouse clicks, it is possible to write tests against the possible regressions. The robot could know where to click from the methods like JTable.getCellRect and JTree.getPathBounds. These relative coordinates can be later translated into the screen coordinates (needed by the robot) with the existing static methods of the SwingUtililities. It should test the node expanding, node collapsing, tree and table cell editing, single and multiple selection and probably table column resizing and reordering with mouse.

The changes of the tree and table state can be checked with the methods like TableModel.getValueAt, ListSelectionModel.getSelectedRows or JTree.getPathForLocation, avoiding the pixel-to-pixel comparison that (due fonts) will differ between Classpath and Sun's implementations.

Mauve already contains two such tests (TreeRobot and TableRobot), but they still do not cover all cases.

Mauve Tests for javax.imageio

Write Mauve tests for reading in images. You could use the test images at and write Mauve testlets that load each image from a file. Compute a hash (such as SHA-1) over the contents of the DataBuffer. If the hash matches, the test succeeds.

Generator for Mauve tests

Write a program which automatically generates basic Mauve tests.


Script for running regression tests

Write a script that once a night checks out Classpath from cvs, compiles it, runs the Mauve test suite (also from cvs) on it using some free JVM (e.g. Kissme), and posts the results to some web site. For comparison, it would be very helpful if the same Mauve testlets were also run with a current Sun JVM.

Integrate Classpath's testsuite into Mauve

Classpath has a rather small number of tests in the subdirectories test/ and testsuite/. Look through these tests and check whether the same functionality is already tested by Mauve. If not, write a Mauve testlet and submit it to . The goal is to remove the test suite from Classpath.

Script for running gjdoc (on builder)

Write a script that once a night checks out Classpath from cvs, runs gjdoc on it, and posts the generated documentation on some web site. While you're at it, fix gjdoc so it copies embedded documentation images (classpath-tools support request #102205).

gjdoc completeness checking

Another task related to running gjdoc nightly is to modify gjdoc so that it can generate japi-style output. Then we could easily generate a web page showing which classes and methods do not have documentation.

JAR file verification

Native Stuff


Security Audit

We need to make a pass over the Classpath Java source, making sure that all required calls to the SecurityManager are in place. At the same time we need to ensure that there is no way to get around SecurityManager by directly calling code in gnu.*. See for a list of tasks related to the security audit and security testing. (Some of these tasks are gcj-specific.)

Security Testing

We need Mauve tests for all the calls to SecurityManager. Additionally, enabling a security manager will probably reveal code in Classpath that needs to be wrapped in AccessController.doPrivileged().



There are still numerous bugs in the JAXP transformer implementation (gnu.xml.transform), and some bugs in the XPath implementation (gnu.xml.xpath). The conformance page is at and you can contact to get the conformance test harness. The largest areas for improvement are:

Also, an implementation of EXSLT ( would be much appreciated.


There is most of an XML schema datatypes implementation hiding in ClasspathX JAXP CVS. However, we need an XML Schema parser and validator and for this to be integrated into JAXP and the DOM implementation. A RELAX-NG parser and validator would also be much appreciated.


We could probably do with an implementation of the XML binding, SOAP, and XML-RPC APIs. A Google Summer of Code proposal for this was written by Andrew Hughes.

Related Projects

Help GNU Crypto

Help Classpath-X

Google Summer of Code

ClasspathOpenTasks (last edited 2008-03-24 16:29:38 by AndrewHughes)