Attention GCJ devel team

Attention GCJ devel team

[James Williams]

Attention GCJ devel team

To Whom it may concern,

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

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

I am currently planning to include test writer functionality that will =
also create a testing framework (Tester for each object) and aggregated =
package Test objects used by the junit TestRunner for use in "JUNIT".

I am probably 3 weeks from finishing this.

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

I'd also be looking for feedback about other possible enhancements.  The =
code generated by the tool can be released under any license that the =
person generating the code desires. Please let me know if your =
interested in evaluating the tool which I plan on releasing under the =
LGPL license.

kind regards

James Williams

Re: Attention GCJ devel team

[Bryce McKinlay]

James Williams wrote:

>I am currently working on a tool that will generate class stubs complete
>with javadoc from javadoc specifications.  In your FAQ a person
>mentioned that "Considering that new Java APIs come out every week, it's
>going to be impossible to track everything."  I believe the tool I am
>developing may reduce this development challenge for you substantially.
>
From my perspective the value of this would be that when a new specification 
>came out, the api converter could be run providing a clean framework 
>complete with all the new and deprecated api's and then the intergrator 
>could copy the existing code from the current libgcj implementation into 
>the new framework.
>

This sounds like an interesting and useful tool. However, I don't know 
whether or not we can, from a legal perspective, generate code 
directly/automatically from Javadocs. I suspect we'd have to ask the FSF 
legal people whether or not this is safe.

regards

Bryce.

Re: Attention GCJ devel team

[Nic Ferrier]

Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

> James Williams wrote: 
>  
> >I am currently working on a tool that will generate class stubs complete 
> >with javadoc from javadoc specifications.  In your FAQ a person 
> >mentioned that "Considering that new Java APIs come out every week, it's 
> >going to be impossible to track everything."  I believe the tool I am 
> >developing may reduce this development challenge for you substantially. 
> > 
> >From my perspective the value of this would be that when a new specification  
> >came out, the api converter could be run providing a clean framework  
> >complete with all the new and deprecated api's and then the intergrator  
> >could copy the existing code from the current libgcj implementation into  
> >the new framework. 
> > 
>  
> This sounds like an interesting and useful tool. However, I don't know  
> whether or not we can, from a legal perspective, generate code  
> directly/automatically from Javadocs. I suspect we'd have to ask the FSF  
> legal people whether or not this is safe. 

We had the same issue with ClasspathX and I think the result was that
it's not legal (sun have (c) on the javadoc produced text).

But I don't have any copy of an FSF mail so you may as well ask again.


However, such a tool would still be useful, just as a monitoring tool.


Nic

Re: Attention GCJ devel team

[Raif S. Naffah]

did the original poster mean when saying "generate ... from javadoc
specifications"

a. generate the code from the _output_ of the JavaDoc tool, or
b. generate the code from .java files (source code) adorned with JavaDoc
tags?

if it's the latter would that still be legally challenging?


cheers;
rsn
----- Original Message -----
From: "Nic Ferrier" <nferrier@tapsellferrier.co.uk>
To: "Bryce McKinlay" <bryce@waitaki.otago.ac.nz>
Cc: "James Williams" <james_williams@optusnet.com.au>; <java@gcc.gnu.org>;
<gcc@gcc.gnu.org>
Sent: Monday, April 22, 2002 4:39 PM
Subject: Re: Attention GCJ devel team


> Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
>
> > James Williams wrote:
> >
> > >I am currently working on a tool that will generate class stubs
complete
> > >with javadoc from javadoc specifications.  In your FAQ a person
> > >mentioned that "Considering that new Java APIs come out every week,
it's
> > >going to be impossible to track everything."  I believe the tool I am
> > >developing may reduce this development challenge for you substantially.
> > >
> > >From my perspective the value of this would be that when a new
specification
> > >came out, the api converter could be run providing a clean framework
> > >complete with all the new and deprecated api's and then the intergrator
> > >could copy the existing code from the current libgcj implementation
into
> > >the new framework.
> > >
> >
> > This sounds like an interesting and useful tool. However, I don't know
> > whether or not we can, from a legal perspective, generate code
> > directly/automatically from Javadocs. I suspect we'd have to ask the FSF
> > legal people whether or not this is safe.
>
> We had the same issue with ClasspathX and I think the result was that
> it's not legal (sun have (c) on the javadoc produced text).
>
> But I don't have any copy of an FSF mail so you may as well ask again.
>
>
> However, such a tool would still be useful, just as a monitoring tool.
>
>
> Nic
>
>

Re: Attention GCJ devel team

[Oskar Liljeblad]

On Monday, April 22, 2002 at 15:10, Bryce McKinlay wrote:

> >I am currently working on a tool that will generate class stubs complete
> >with javadoc from javadoc specifications.  In your FAQ a person
> >mentioned that "Considering that new Java APIs come out every week, it's
> >going to be impossible to track everything."  I believe the tool I am
> >developing may reduce this development challenge for you substantially.
> >
> >From my perspective the value of this would be that when a new 
> >specification came out, the api converter could be run providing a clean 
> >framework complete with all the new and deprecated api's and then the 
> >intergrator could copy the existing code from the current libgcj 
> >implementation into the new framework.
> 
> This sounds like an interesting and useful tool. However, I don't know 
> whether or not we can, from a legal perspective, generate code 
> directly/automatically from Javadocs. I suspect we'd have to ask the FSF 
> legal people whether or not this is safe.

I wrote a program similar to what you describe some time ago. It is called
DeDoc and can be downloaded from
http://freshmeat.net/redir/dedoc/1802/url_tgz/dedoc-0.12.tar.gz.
It reads HTML (generated by javadoc from java source files) and writes
source files for each class encountered. I don't know if anyone actually
uses/used it...

The same question came up that time - is it legal to use code automaticly
generated from Javadoc [in GPL programs]? I wrote RMS to ask about it,
and he forwarded my email to Eben Moglen. I quote from the letters I
received:

Eben Moglen writes:

  The act of removing the entity definitions from the documentation and
  reusing them for reimplementation is the same whether an automated
  process is used or the copying is done by hand.  So if the single
  question is whether running the DeDoc routine is legally more
  problematic than doing the work by hand, the answer is no.  From the
  copyright point of view it makes no difference whether the data was
  compiled by a very automated or less automated process.

  The larger question is whether the copying that is taking place, no
  matter how, could conceivably be held infringing.  Numerous factors
  enter into this, including what proportion of the HTML documents are
  being copied, whether the entity signatures could satisfactorily be
  characterized as functional rather than expressive, what proportion
  the signatures bear to the size of the finished work, and even what
  the identifier names are.  Some measures of ordinary prudence should
  be taken.  Where identifier names do not require to be externalized
  for compatibility with existing library linkages, they should be
  changed.  Where other aspects of the signature are not similarly
  required, they too should be reconsidered.  Before release we should
  review the code a little more closely to make sure that what could be
  reinvented rather than copied has been.

Here's more from Eben Moglen:

  OL> The signatures information is the base for about 95% of the output of
  OL> DeDoc (counting bytes of code.) This may seem much, but know that
  OL> what DeDoc generates is not usable immediately. It still takes
  OL> heavy (re)engineering efforts to complete the library which DeDoc
  OL> provides the code-base for. Once the library is completed, the signatures
  OL> will probably be less than 2% of the finished work.

  Then we are not going to worry about the matter for now.  The
  proportion of signature to other HTML input to DeDoc is also probably
  low, because of the text comprising the rest of the documentation.  So
  our case against an infringement by copying claim is essentially a
  fair use defense: small amounts of copying from the original document,
  functional in character, representing a small proportion of our
  finished work.  Under US copyright law this would be a sound position
  and I am comfortable that we could defend it.  Let's be sure to check
  at the later stages of the project, to be sure that our assumptions
  turned out to be right.

Oskar Liljeblad (oskar@osk.mine.nu)

Re: Attention GCJ devel team

[Bryce McKinlay]

Oskar Liljeblad wrote:

>I wrote a program similar to what you describe some time ago. It is called
>DeDoc and can be downloaded from
>http://freshmeat.net/redir/dedoc/1802/url_tgz/dedoc-0.12.tar.gz.
>It reads HTML (generated by javadoc from java source files) and writes
>source files for each class encountered. I don't know if anyone actually
>uses/used it...
>
>The same question came up that time - is it legal to use code automaticly
>generated from Javadoc [in GPL programs]? I wrote RMS to ask about it,
>and he forwarded my email to Eben Moglen. I quote from the letters I
>received:
>

Thanks Oskar. I believe we can conclude from this that it is ok to use 
automated tools to generate templates for implementing classes from 
Javadocs, provided that it is only the member names and signatures that 
are being copied and not the documentation itself.

regards

Bryce.