Project Proposal Guidelines

This document describes a list of guidelines that can help you in preparing your application form for the Summer of Code 2013. We strongly suggest also looking at the following resources:


Please follow all the guidelines and rules defined by Google, as these are the most important requirements. A program like the Summer of Code can be very difficult to manage, especially for students in the European Community whose summer schedule is usually later than that in the United States. This is why we recommend that students do not work on other projects outside the GSoC, or limit the time spent on these projects to a maximum of 10 hours per week, depending on the task being proposed.

All applicants must be familiar with the GNU/Linux platform, have strong knowledge of build tools like make and be reasonably fluent in the Java and/or C programming languages as appropriate. We also require some understanding of how the Java Platform works.

The GSoC is a means of learning and gaining experience, and our mentors will do everything they can to help the student, but a student must start from a solid basis already to have a chance of successfully complete the program.

Proposal Outline

The guidelines offered by the GSoC FAQ page are generally enough for us. The FAQ provides two examples, linked here for reference: and


Please note: The following are just suggestions, since the Summer Of Code project requires you to write a proposal, and we are definitely open to experiments and other ideas.

* Port the Gtk+ AWT support to Gtk+3

Most GNU/Linux distributions now ship with Gtk+3, but GNU Classpath still uses a Gtk+2 peer as its primary means of providing GUI support. This project would, as a minimum, require getting GNU Classpath's Gtk+ peer to build with Gtk+3 and, ideally, use some of the new features available therein. The Gtk+ developers provide a guide on the porting process. Knowledge of C and the autotools/make build system is required.

* Update the SQL interfaces

GNU Classpath provides versions of the SQL interfaces, used by database providers, to a Java 1.5 level. Java 1.6 & 1.7 update these interfaces with new features which are now being used by database providers (e.g. the Java PostgreSQL connector). This task would involve implementing the missing classes and methods so that these database providers would work with GNU Classpath. Knowledge of Java is required, as is basic knowledge on how to use the autotools/make system to build GNU Classpath.

* Update the JMX implementation

Google's Summer of Code in 2006 provided GNU Classpath with an implementation of the interface and a partial implementation of the JMX standard on which it depends. This project would involve updating this implementation to bring it up-to-date with the newer 1.6 & 1.7 versions. There is some flexibility as to whether the student wishes to target updating the existing implemented areas or provide code for some of the packages (e.g.,, which are completely absent; a list of missing classes/methods can be found in this JAPI comparison against OpenJDK 6. Knowledge of Java is required, as is basic knowledge on how to use the autotools/make system to build GNU Classpath.

* Port the GConf peer to the new Glib interfaces.

As with the Gtk+ peer mentioned above, the world has moved on since a GConf peer was added to GNU Classpath and such functionality is now provided at a lower level by Glib. This project would involve updating the peer to work with the new interfaces. Knowledge of C and the autotools/make build system is required.

* Port the GStreamer peer to the 1.0 interfaces.

Similar to the last project, the interface to GStreamer has changed between 0.10 and 1.0 and the peer needs updating. Knowledge of C and the autotools/make build system is required.

* Improve the Qt peer.

A Qt peer is available for GNU Classpath, in addition to the Gtk+ one, but it has never really been maintained since the time Qt4 was released. This project would be partly investigatory and open to how the student wanted to proceed, based on the issues they found with the existing peer and how they wanted to improve it. Knowledge of C and the autotools/make build system is required.

* Add more ImageIO support

Many areas of the JDK provide interfaces which then have provider implementations. One such is ImageIO which provides support for loading images/photos in various formats. A suitable project for Google Summer of Code would be to provide support for a format that is not yet supported, or leverage an existing library to support many new formats (e.g. ImageMagick). Such work may also be applicable to IcedTea/OpenJDK. Knowledge of C, Java and the autotools/make build system is required.

* Add more sound support

As with the previous project, support for playing/writing media files is dependent on providers and a suitable project would involve providing support for a format of the student's choice. Again, this may also be applicable to IcedTea/OpenJDK and requires knowledge of C, Java and the autotools/make build system.

* More Ideas, not strictly related to GNU Classpath:

IcedTea, a sister project, applied as an organisation this year but wasn't accepted. The list of tasks proposed for the IcedTea project is at the following link:

You may find some of those tasks interesting as well.

GoogleSoC2013 (last edited 2013-04-15 08:52:17 by neugens)