GJDoc

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

 



On Fri, 10 Mar 2006 13:40:21 +0100
Julian Scheid <julian@xxxxxxxxxxx> wrote:

> 
> Stuart Ballard wrote:
> > On 3/1/06, Julian Scheid <julian@xxxxxxxxxxx> wrote:
> > 
> >>What I'd really like to do is completely replace the parser with a new
> >>one written from scratch (preferrably, a generated one.)  In addition,
> >>the parsing and type resolution steps should be cleanly separated - they
> >>are somewhat intermingled at the time.
> > 
> > 
> > What are the odds of replacing it by calls into ecj's parsing engine,
> > since that's already pretty mature and implemented in pure Java?
> > 
> > The licensing problems that may exist at this time seem to be
> > resolvable, as evidenced by the plan to use ecj as gcc's Java frontend
> > in the future...
> 
> So I've finally got a chance to look at the ecj parser yesterday, and 
> indeed it seems to be perfectly suited for the task.  It even comes with 
> a Javadoc comment parser which appears to be adaptable for Gjdoc's 
> purposes.  Assuming that you're right about the licensing issues, I 
> agree that this lends itself very well.  Thanks for the heads-up.
> 

Not to put a spanner in the works, but is integrating with ecj possible now?
I notice the mail quoted above says 'in the future', and, given this and
Tom's original proposal, I'm wondering whether using ecj is reliant on GPLv3.
If this is the case, then it won't be available until at least January next
year...
 
> Now one big problem remains, namely integrating the new parser into 
> Gjdoc - as I said, the parsing step is not cleanly abstracted away, so 
> unfortunately this amounts to quiet a lot of work - so much work 
> actually that I am considering doing a complete rewrite of the Gjdoc 
> core instead, something which is long overdue anyway.
> 

Yes, this was my grasp of it too.

> Given that a lot of last year's work on Gjdoc went into the doclet, 
> which can be retained unmodified, and now that I'm quiet acquainted with 
> the requirements and peculiarities of the system, this isn't as big an 
> undertaking as it may sound at first.
> 
> I'll look further into this during the next week(s) and keep you up to date.
> 
> Julian
> 

Thanks,
-- 
Andrew :-)

Please avoid sending me Microsoft Office (e.g. Word, PowerPoint) attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
Support OpenDocument instead.

Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }

"Value your freedom, or you will lose it, teaches history. 
`Don't bother us with politics' respond those who don't want to learn." 
-- Richard Stallman

The views expressed above are representative of my own personal
opinions, and not necessarily those of the University of Sheffield.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://developer.classpath.org/pipermail/classpath/attachments/20060310/fbaece1d/attachment-0001.pgp

[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux