On Wed, 23 May 2001, Craig R. McClanahan wrote:
> I know Costin loves evolutionary change :-), and it's certainly a valid
> approach to Jasper.
>
> But there is also another approach we should consider - a green-field
> recoding of at least some of the major components (conforming to an
> agreed-upon overall architecture, of course).
> NOTE: For most of the rest of the overall problem (the PageContext
> implementation, how Jasper fits in with the servlet container, and so
> on) evolution is probably a very reasonable strategy. On the compiler,
> though, I'm not so sure.
If we are talking about the compiler ( or code generator ): I partially
agree, the current architecture will get a lot of pressure from more
complex optimizations or tricks.
But before we can even start to change the generator we need to do the
initial refactoring and get the other components in order ( runtime, etc).
We can also get some optimizations in, and use that to learn what's needed
from a new generator architecture.
I just don't think the new generator can happen in a 3.4 space - my goal
is just to enable an effort to rewrite it, and gather as much information
as possible about it's requirements.
In any case - whatever happens in the current generator with regard to
generated code will still be usefull for any new generator architecture.
And if certain optimizations can't be done - that's even better, because
it would help us understand what's needed.
I had big hopes for an XSLT based generator, and I still think it may be a
good way to implement the code generator - and I hope to hear other
ideas.
Costin
