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:[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]>). Graydon Hoare <mailto:[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]>. 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:[EMAIL PROTECTED]> or to any of the individuals mentioned above if you want faster replies.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
