GNU Classpath development and gcc integration

[Mark Wielaard <mark at klomp dot org>]

Hi all,

Probably bad timing just after possibly haven broken the build on small
memory machines but I thought it would be good to explain the GNU
Classpath development plan and how we integrate with gcc. (BTW I can
reproduce the problem now by artificially limiting the virtual memory
size with ulimit -v450000. Trying to find a solution now.)

For a very high level overview of were we are with respect to providing
a Free Software alternative to the proprietary java platform and a kind
of road map see: http://developer.classpath.org/support/
Escaping the Java Trap
A practical road map to the Free Software and Open Source alternatives

The GNU Classpath core libraries are used by a large number of runtimes
and alternative execution environments (like the traditional kaffe
interpreter/jit, but also by integration in mono through ikvm byte code
transformation). But it is clear that the most important, in terms of
users and in terms of stability/production quality, is the combination
with gcc/gcj. Lots of GNU/Linux distributions now rely on the stable
gcc/gcj releases with integrated GNU Classpath to package various
(large) programs written in the java programming langauge (see the
support document above).

We noticed that most of our bug reports (50% at least) came through gcj.
So we have, with the help of Daniel Berlin, merged our old savannah bug
database with the gcc bugzilla. This also allowed us to get similar
cvs/svn-commit messages automagically inserted whenever a fix hit the
classpath/gcc repositories. This has been a very big help.

On the library development front we have tried to separate most of the
development from the main gcc tree. Most development is now done
directly "upstream" on savannah with occasional merges back into the
libjava/classpath tree in gcc. Thanks again to Daniel Berlin for
subversion help and to Tom Tromey for making this split possible.
Merging has become a lot easier with subversion. We now import new GNU
Classpath snapshots into a special branch:
svn+ssh://gcc.gnu.org/svn/gcc/branches/CLASSPATH/libjava/classpath
and then merge that into the trunk libjava/classpath tree. This has
worked very smoothly for us.

The traditional design of the java compiler and core libraries means
that there is still a tight integration between the two. But we hope
that the current arrangement allows us to do rapid development of the
core libraries without disrupting the normal gcc development flow. More
details about the setup can be found in the libjava/HACKING file in svn.

We try really hard not to disrupt the normal flow of GCC development.
For any large build/integration changes we contact Mark Mitchell as
release manager, but should probably also more often post a note to the
main gcc list in the future. If we somehow fail and we cause any
trouble, please do let us know on the java@gcc.gnu.org list. We try very
hard to solve any issues asap.

I am mainly one of the library guys, maybe some of the frontend people
can tell more about future gcj plans. The current status of the gcjx
frontend is described at http://gcc.gnu.org/wiki/GCJX%20status

Thanks for all the cooperation. The GCC community has been very helpful
and supportive of our efforts.

Thanks,

Mark

-- 
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html

Join the community at http://planet.classpath.org/

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