Re: Attention GCJ devel team

[Nic Ferrier]

Tom Tromey <address@hidden> writes:

> >>>>> "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. 

If we could just get an accurate list of changes it would be useful.


Nic