classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Attention GCJ devel team


From: Tom Tromey
Subject: Re: Attention GCJ devel team
Date: 19 Apr 2002 11:51:03 -0600

>>>>> "James" == James Williams <address@hidden> writes:

James> I am currently working on a tool that will generate class stubs
James> complete with javadoc from javadoc specifications.  In your FAQ
James> a person mentioned that "Considering that new Java APIs come
James> out every week, it's going to be impossible to track
James> everything."  I believe the tool I am developing may reduce
James> this development challenge for you substantially.

James> Effectively this tool can generate class stubs (and
James> automatically implement setters and getters, assign final
James> variable values (using reflection) for the entire J2SE api in
James> about 20 minutes.  As near as I can tell this tool does not
James> violate the SUN license (that I accepted when downloading the
James> spec) because effectively the software does exactly what people
James> would do were they implementing a clean room version of the
James> api.

Hi James.

First, most of the gcj discussion happens on the address@hidden
mailing list.  For this tool, the address@hidden list might be even
more appropriate.  I've moved this to the latter.

We'll probably need someone at the FSF, maybe RMS, to look at the
legality of this approach.  I agree on principle it seems like it
should be legal, but my experience is that such principles rarely hold
where the law is concerned.

I've CC'd RMS so he can tell us what the next step might be.  It may
take him a while to reply, as he gets a lot of email, so please be
patient.

James> After the Test Writer I plan on adding a code intergrator.
James> From my perspective the value of this would be that when a new
James> specification came out, the api converter could be run
James> providing a clean framework complete with all the new and
James> deprecated api's and then the intergrator could copy the
James> existing code from the current libgcj implementation into the
James> new framework.

For existing classes, I think it would be more useful if the tool just
generated a stub for every new method or field.

Tom



reply via email to

[Prev in Thread] Current Thread [Next in Thread]