The Java generator was rubbish.

How come you were not using the Velocity generator? I guess only the Java
was converted to using that, or it was never merged down from M2 to trunk?
The velocity templates approach seemed simple and useful enough.

On 24/09/2007, Alan Conway <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2007-09-24 at 16:56 +0100, Robert Greig wrote:
> > On 24/09/2007, Alan Conway <[EMAIL PROTECTED]> wrote:
> >
> > > Lets be clear: I did not "throw away" anything. I did discuss it with
> > > all of the developers who are affected by it, and I think they all
> agree
> > > it was a good move.
> >
> > Did you discuss it on the qpid-dev list at all?
>
> It's possible I didn't, in which case I apologize & will be more careful
> in future.
>
> >
> > I didn't see any discussion of it but I would be interested to
> > understand the issues you faced since it may well affect Java too
> > either now or in the future.
>
> Principal issue was the effort required to make any non-trivial changes
> to the templates or add new templates. This was the pre-velocity
> generator so velocity may have improved things. The main issues:
>
> - most of the generation logic was not in the templates but in Java
> code, so almost every change required modifications to the java
> generator. The ruby templates are written in ruby so the full power of
> the language is available in the templates.
> - gentools templates are large and repetative. The ruby version
> automates a lot of the tedious stuff, e.g. automatically inserts
> copyright notices and header guards, handles indenting, generates some
> common c++ constructs etc. which speeds up template writing.
> - The java generator is huge (about 8000 lines) and difficult to
> maintain. The ruby generator is about 300 lines for the AMQP core and
> another 200 of C++ helper functions.
> - the Java generator is greatly complicated by its "multi-version"
> classes. For C++ I don't think this is the right approach to
> multi-version support (I'm not sure it is for Java either but that's for
> the people who will implement it to decide.) Removing it makes the
> generator much simpler to use & maintain.
>
> Cheers,
> Alan.
>
>

Reply via email to