Hi, On Thu, 2004-03-25 at 16:29, [EMAIL PROTECTED] wrote: > As list administrator, your authorization is requested for the > following mailing list posting:
Oops. I believe I hit the spam button. Sorry Thomas. Hope the rest of our cooperation goes a bit smoother. ________________________________________________________________________ > From: Thomas <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Tests > Date: Thu, 25 Mar 2004 16:28:51 +0100 > > I'm a long time Java programmer (over 5 years now), with a _lot_ of experience > in quite obscure parts of the libraries. > As an effect I know of quite some annoying bugs in Suns implementation of the > various base classes (mostly Swing stuff). I am interrested in creating tests > to test for these bugs in the (coming) implementation of the same API in G.CP Very nice! Welcome, welcome! > With such long experience on Suns JVMs you can guess I looked into there > sources ones or twice. I'm assuming this means you can't accept > implementations of API stuff from me. > But does this mean I can't create tests? What about APIDocs, and what about > simple bugfixes? Writing tests and documentation is fine. And really appreciated! The reason we don't accept code from people who have studied other proprietary implementations is summarized at: http://www.gnu.org/software/classpath/docs/hacking.html#SEC2 "If it turns out that your code was not developed in a clean room environment, we could be very embarrassed someday in court. Please don't let that happen." As you probably know, creating a a compatible implementation means writing much code that will look similar. To proof that the similarity doesn't come from copying another implementation, but because we are follow the spec so precisely, we use the defense that the people who wrote it have not looked at any other implementation of those methods and classes. If you would like to help with testing then please check out the Mauve project which we use for much of our testing purposes. http://sources.redhat.com/mauve/ Also taking an existing free program written in the java language and trying to make it work with gcj, kaffe or another VM based on classpath is really appreciated. See the following email for some more explanation "GNU Classpath 0.08 - How to use it": http://mail.gnu.org/archive/html/classpath/2004-03/msg00093.html On the documentation front we are missing a good overview document. We do already have some nice API documentation (although it can certainly use more attention for some packages/classes): http://www.klomp.org/mark/classpath/doc/api/html/ A good overview document should tell you "this is what we have", "this is how it fits together" and "this is how you use it to create more free software". Most documentation tells about the proprietary implementations. And although we try to be as compatible as possible to make it easy for people to move from a proprietary platform to a free one, we are not there yet. So what we really need is a document that describes everything from the point of view of the free implementation that we have now. > Please cc answers as I'm not subscribed. Please subscribe to the list. It makes communication a but easier. I need to explicitly accept non-subscriber email (darn spam...) Cheers, Mark
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath