Hopefully this actually gets delivered. For those who don't know, the GNU mailserver crashed hard. Commence primary ignition ... Here are some of my general thoughts on the topic of a Classpath-Gcj merger. I'll try to read through some of my backlogged mail and respond to any specific points not covered here. 1. What does this all mean? Well, in a way Classpath and Gcj are trying to do two different things. Classpath has basically been trying to create a class library for Japhar, with the idea that it would be adapted to other JVM's as needed. Gcj has been developing a Java fronted to gcc, which allows for native compilation of Java programs, with an eye towards their embedded systems market. The real area of overlaps seems to be that gjc needs a free class library. So when we say the "projects" are merging, what I interpret that as is that we are combining our class library efforts in some fashion. Most of gjc should not be affected at all. Similarly, my goal of creating a class library that works with multiple VM enviroments - particularly Japhar - has not changed. 2. Licensing. I'm not familiar with the libstdc++ license, but what was sent to the list appears to be similar to the Guile license. Is that a correct interpretation? 3. Brief description of overlap. I looked at the latest gjc code from CVS. The class library is not nearly as far along as I had thought, which is good news. Here is my first glance reaction at what we might want to do as far as merging the code. Covering mostly 1.1. The following packages exist in Classpath in some form, but not in gjc, thus the Classpath version should be used: java.applet (still need an appletviewer) java.beans java.math (I thought Per had a version of this?) java.sql The following packages exist in gjc in some form, but not in Classpath java.util.zip java.util.jar Note that Loren Peace is supposedly nearly done with a version of these for Classpath, but we have yet to see code. Gjc's java.util.jar looks to be missing most classes, so if Loren comes through there, we might want to use implementation. The rest of the packages obviously are unimplemented or overlap. These are: java.awt.* - Gjc has started some implementation, but it is mostly stub or skeletal classes and many are missing. Classpath has almost all of the AWT stuff written (though not yet working) and a working set of GTK+ peers. I think the Classpath code should be used here. java.io - Classpath is written to be fully 1.2 compliant, is fully documented, and has about 20 more classes written than gjc. I suggest using the Classpath version. We should look at a few specific classes to see whether the gjc implementation might be better. For example, my versions of BufferedInputStream and BufferedReader are pretty hacky. java.lang - Both projects have a fairly complete implementation. I'm not sure what to do here. Will require further investigation. java.lang.reflect - Both have something here, but this is rather VM specific, so probably isn't all that relevant. java.net - Both projects have a relatively complete implementation. Classpath's java.net was the very first thing I wrote almost two years ago and I think it may not be the greatest. Assuming the gjc guys think their implementation is solid, it might be best to use that, though comparing specific classes for useful tricks might be a good idea. java.rmi.* - Don't have any, but I believe Transvirtual Technologies has said they are going to release an LGPL'd version of this. Something to think about. java.security.* - gjc has a couple classes written, while Classpath has a nearly full (but not yet working, IIRC) java.security.* implementation courtesty of Mark Benvenuto. The Classpath version should be used. java.text.* - Both projects have a lot of this implemented. I wrote java.text for Classpath and it is not yet debugged. If the gjc guys feel confident in theirs, we might want to use it. This one requires some investigation. I do think there are some classes Classpath wrote that gjc did not. It looks like we might be further along in locale specific things too. java.util - Classpath appears to have a much more complete implementation and thus should be used, with the overlapping classes examined for superior implementations. 4. Documentation. Someone mentioned that documentation is not important for the class libraries because this information is readily available from other places. I strongly disagree. Free software needs free documentation. While I am going forward with the objective of making a version that is 100% compatible with the Sun reference implementation, others may not share this goal. If they exercise their right to make modifications, they will also want to be able to modify the documentation, which would be impossible without a free version. Additionally, the Sun class library documentation I've read is very deficient in many areas. Surely we can (eventually) do a better job. I would like to not only be able to generate high quality browseable, javadoc like documentation, but also figure out a way to auto-generate a Texinfo manual that could be used to create a hardcopy book similar to the Sun class library reference manuals. Classpath would be done twice over if we had not done any documentation. I'm glad we've taken the time to do the docs to at least the level we have. 5. Coding Style. I hate to even get into this because it is a clear holy war topic. I have my own style, similar to the GNU C coding style, because that's what I'm used to and because I hate Sun's style. (There is simply no excuse for not making all method names begin in column zero, where they are easily located in vi, IMNSHO). Let's concentrate on getting the important stuff done first, and worry about this later when we have the luxury of time to argue over this. 6. Mechanics of merger. New copyright headers, etc. Boring housekeeping stuff we can hopefully automate at least somewhat. Some thought needs to be put into how we handle CVS, mailing lists, bug tracking, etc. This might be one area where Cygnus' superior development infrastructure might help out. -- Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
