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 [EMAIL PROTECTED] 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/
signature.asc
Description: This is a digitally signed message part
