This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Attention GCJ devel team
- From: Nic Ferrier <nferrier at tapsellferrier dot co dot uk>
- To: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- Cc: James Williams <james_williams at optusnet dot com dot au>, java at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: 22 Apr 2002 07:39:33 +0100
- Subject: Re: Attention GCJ devel team
- References: <001e01c1e797$c91c2f30$c47831d2@computer><3CC38926.90804@waitaki.otago.ac.nz>
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