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