Tests (Was: Classpath post from address@hidden requires approval)

[Mark Wielaard]

Hi,

On Thu, 2004-03-25 at 16:29, address@hidden 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 <address@hidden>
> To: address@hidden
> 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