The status of Classpath (in brief)

[Mark Wielaard]

Hi Gang,

People contact me from time to time with questions about the status of
GNU Classpath and how they can help. I don't have a good story yet, but
below is an one example of something that I send quickly before going on
vacation. I am back now btw :)

Hope to make this into a more standard reply and/or webpage describing
the effort. If you have any comments and/or suggestions to make it more
clear, please yell.

Cheers,

Mark

> RMS asked to me contact with you about implement the free Java class
> libs. I would like to know the current status of your project.
> Could you send me a brief explanation?

[...]

GNU Classpath creates a free alternative for the core libraries that
come with what Sun calls the J2SE. But GNU Classpath is only the library
implementation. It provides the core libraries mostly written in the
java language and offers a VM interface for integrations into larger
development environments and were possible a C/JNI implementation for
POSIX like systems to interface with the rest of the system.

It does not offer a compiler (for which we use GNU Compiler for Java -
gcj and/or Jikes). It also doesn't offer a runtime environment for which
we again rely on gcj, which can both do traditional byte-code
interpretation and compile programs written in the java programming
language to native code (portable to lots of architectures since gcj is
a GCC frontend). The native code compilation of gcj does give us a nice
advantage over the traditional proprietary java implementations since it
produces code which runs very fast without the need for interpretation
or just in time compilation of byte-code.

Other free runtime environment/compiler and research projects which
build upon classpath (excluding any proprietary projects, which are free
to build upon GNU Classpath under certain conditions, but which we won't
promote to others) are listed at our homepage under:
http://www.gnu.org/software/classpath/stories.html

The most notable one is the kaffe project <http://www.kaffe.org/> which
is a complete development environment for programs written in the java
language distributed under the GPL which comes with its own compiler,
tools, byte code interpreter and just in time compiler. It used to come
with its own implementation of the core libraries but since the
beginning of this year they are slowly converting it to build upon GNU
Classpath. The libgcj and kaffe hackers are nowadays the biggest
contributors to GNU Classpath.

A couple of projects around GNU Classpath will meet at the Fosdem
conference in Brussels, Belgium on 21/22 February to discuss how they
can work together better and what the free software community at large
needs to liberate some of the free software programs written in the java
language. (we will also have a meeting with some Debian developers which
are currently unable to support lots of free software [or rather open
source] programs which are written in the java language, distributed
under free software licenses, but depending on proprietary runtimes and
libraries which prevent them from being distributed in a useful manner.)

GNU Classpath currently has fairly complete implementations for the
following packages: java.beans, java.io, java.lang, java.math, java.net,
java.rmi, java.security, java.sql, java.text, java.util, java.util.jar,
java.util.zip.

The following packages are in a less complete state and need more work
before we can claim that they are useful for developers: java.applet,
java.awt, java.util.prefs, java.util.logging, java.nio, java.applet and
javax.print. And some (minimal) parts of javax.swing. Please ask on the
GNU Classpath mailinglist <mailto:address@hidden> for more detailed
status and who is working on what.

Some additional tools are bundled in the cp-tools project (javap, gjdoc,
serialver). And some additional libraries are developed by the GNU
ClasspathX project (javax.mail, javax.xml, javax.servlet, etc). The GNU
Crypto project provides a javax.crypto implementation on top of its own
crypto library and the Jessie project provides some javax.net.ssl
classes. We are busy importing the gnu.regex packages for
java.util.regexp support.

A (incomplete) task list is currently hosted at:
http://www.reali.ch/~reali/classpath/tasks.html
(Savannah does not let us update out webpages yet, it will move to
http://www.gnu.org/software/classpath/ soon.)

These tasks range from writing simple tests (for example to check that
all equals, hashcode or serializable implementations work according to
specification), creating tools for jar file and keystore manipulation,
creating documentation for undocumented classes, writing a guide on
using free compilers and runtimes like gcj and kaffe for new projects,
till creating larger missing standard libraries like javax.imageio or
javax.swing.text and subpackages or specialized classes that need lots
of expertise like java.awt.geom.Area, which requires someone with lots
of numerical computation and computational geometry expertise.

For a general overview of what GNU Classpath is missing at the moment
compared to some other proprietary closed source JDK libraries. see:
http://japi.sab39.org/htmlout/h-jdk14-classpath.html

Currently we create a snapshot release of GNU Classpath every three
months to show our progress. These snapshot releases are then
incorporated in the various runtime/development environments. We are
currently at snaphot release 0.07. The stated goal for GNU Classpath 1.0
has always been at least as complete as 1.1, including documentation,
test-suites and a stable API for integration into the different
compilers and execution environments that build upon it. But in practice
we are driven by what people actually use or want to use. So while we
find the documentation, tests and the Abstract Window Toolkit (java.awt)
support not yet 1.0 material you will find support for lots of 1.4
extensions for the various packages or even complete new packages like
java.nio and java.util.logging in the current GNU Classpath snapshot
releases. Much is driven by the desire of people to run the larger free
software frameworks like JBoss, Eclipse and some of the Apache Jakarta
tools. Most of which now just work on VMs based on GNU Classpath.

AWT support is progressing nicely and is the last real code deficiency
for declaring 1.0 status (there is work on different backends of which
the GTK+ one is the most important, we also hope to provide a ncurses
one). But tests and documentation are still not 1.0 material. Tests are
organised in the Mauve project <http://sources.redhat.com/mauve/>. There
is fairly complete API documentation describing each class and method in
GNU Classpath. But except for the Hacker Guide and VM Integration Guide
we don't have any good "overview" or "this is how you use the libraries"
documentation. This is important to have before declaring 1.0 because it
will show what can really be done with the free implementations.
Nowadays people depends descriptions of the proprietary implementations
which often leads to more "semi-free" programs that don't work on a
completely free system because they will use features which are not
available yet in GNU Classpath.

> I think a free JFC implementation is indispensable for any Java
> application development. JFC has 5 APIs: AWT, SWING, Accessibility,
> 2D, Drag&Drop. (RMS asked me to help the free SWING development).
> Pls tell me your progress on these APIs or other packages you have
> done.

We haven't been focusing very much on JFC classes for GNU Classpath 1.0
since we first wanted to provide a minimal, but complete, core
implementation that could be used by free software developers.
But there has been some work by individuals on the various parts.

AWT was something which we wanted to support for 1.0 and this is
progressing nicely since Red Hat has made it a priority to complete this
part of the library. So there are actually a couple of hackers now
working on completing it. We also have a fairly nice test-suite based on
the Wonka visual test-engine that helps a lot seeing where any remaining
bugs are. Thomas Fitzsimmons <mailto:address@hidden> is the most
active developer on this package and the GTK+ peers. He probably has a
good overview of what works and what still needs work.

SWING consists mainly of stub classes. It was probably a mistake to keep
them around so long since they mainly don't work. There are some
subpackages which are implemented and documented almost completely
though (notably javax.swing.border and javax.swing.undo which were done
by Sascha Brawer <mailto:address@hidden>). Graydon Hoare
<mailto:address@hidden> has been working a bit on the widget and
event framework and he did get a simple JButton working so some of the
foundation classes do work.

2D has been the project that Graydon Hoare <mailto:address@hidden>
has been working hard on the last couple of months. He is creating a 2D
graphics environment on top of existing free software libraries like
Pango, Cairo, ft2 and freetype. Some of his progress can be seen at:
<http://people.redhat.com/graydon/native-java2d-aug28-2003.png>
Sascha Brawer <mailto:address@hidden> has been working on the
geometry classes and works on an alternative font library. 

Accessibility interfaces are complete in javax.accessibility, but need
to be hooked up to the various parts of the rest of the system and in
particular to the GTK+ peers. I don't believe anybody is actively
working on that at the moment. Eric Blake <mailto:address@hidden>
was the last person doing work on this, but he hasn't been active for a
while.

Drag&Drop has some parts implemented in java.awt.dnd[.peer] but these
are mainly stubs at the moment. Michael Koch <mailto:address@hidden>
would be the person to tell you more about this part.

I think the simplest (and most fun) way to contribute for people is by
looking at the free software java applications they already use and/or
want to use with the free VMs that use GNU Classpath like gcj, kaffe,
kissme, sablevm or ikvm.net, etc. One thing that really boosted the
confidence in our library implementation was when people tried (and
succeeded!) in getting for example Eclipse <http://www.eclipse.org/>
working with gcj, kaffe and ikvm. Testing whether free applications run
correctly on a free system gives people a very concrete goal to achieve.

Good places to start are the Kaffe application page and the gcj RHUG
project:
http://www.kaffe.org/compatibility_applications.shtml
http://sources.redhat.com/rhug/

Both have examples of what and how to get things working and have
contact addresses and mailing-lists that can be contacted when people
want more information or to offer help adding libraries and applications
to the collection. If more things work for these projects we can be a
bit more confident that the GNU Classpath libraries (that both gcj and
kaffe use) works correctly. And any bugs or deficiencies found in this
way are clues what is the most important to fix first.

One of the Debian developers who has been very active and who maintains
a couple of free applications that cannot be packaged currently for
Debian main because they depend on parts of Swing is Arnaud Vandyck
<mailto:address@hidden>. He can probably give a list of what he
thinks are important free programs that are currently trapped because
they use Swing.

I will be offline for the next week so please follow up to the GNU
classpath mailinglist <mailto:address@hidden> or to any of the
individuals mentioned above if you want faster replies.

signature.asc
Description: This is a digitally signed message part