On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
> On Wed, 23 May 2001, Casey Lucas wrote:
>
> >
> > btw, If i start tinkering, should I work with jasper34 or the 3.3 stuff?
>
> Difficult question...
>
> The problem with jasper34 is that it doesn't work yet ( the one in
> proposals/jasper34 - I still have to move it in the new repository ). Mea
> culpa - I tried to make big changes instead of the old slow evolution...
>
> I'll start importing the current jasper33 in the new repository and make
> sure it builds, and use it as the first step for 34. Then I'll stick with
> the step-by-step evolution. Merging with jasper40 and xslt can wait a bit.
>
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).
What has struck me about the custom tags pooling question is that we're
trying to make a non-optimizing compiler into an optimizing compiler "from
the ground up", rather than taking advantage of the decades of compiler
writing experience and designing one from the top down.
Just as a for instance about why we might want to consider this, let's
look at a mythical "iterate" tag with a nested tag inside:
<x:iterate from="0" to="999">
<x:foo name="bar" value="<%= ... an expression %>"/>
</x:iterate>
Today, Jasper will do a "new FooTag()" plus all of the associated tag
setup, inside the loop, 1000 times. Tomorrow, using tag pooling can mean
that there will only be at most one create, but you've still got the
allocate/deallocate overhead plus the redundant setXxxx calls.
However, it's perfectly legal for the pseudo-code generated by this page
to look like this (see the examples in the JSP spec):
IterateTag iteratetag = new IterateTag(); // or allocate from a pool
iterateTag.setPageContext(...);
iterateTag.setParent(null);
iterateTag.setFrom(0);
itearteTag.setTo(999);
FooTag fooTag = new FooTag(); // Or allocate from a pool
fooTag.setPageContext(...); // Lifted out of the loop
fooTag.setParent(iterateTag); // Lifted out of the loop
fooTag.setName("bar"); // Lifted out of the loop
... iterate-start implementation ... {
fooTag.setValue(expression);
fooTag.doStartTag();
fooTag.doEndTag();
} ... iterate-end implementation ...
fooTag.release();
fooTag = null; // or recycle to a pool
iterateTag.release();
iterateTag = null; // or recycle to a pool
In other words, you pay either *one* object creation or *one*
allocate/deallocate for the <x:foo> tag instance, and you don't waste your
time doing stuff inside the loop that only needs to be done once.
Optimizing compilers can be made smart enough to do things like this, as
long as you take the time to build in the appropriate knowledge of the
language (in this case, JSP syntax and semantics) that you are
translating. If you happened to take a compiler class along a degree
path, this kind of thing will probably look familiar.
I think we owe it to ourselves to consider whether a completely new
effort, at least for the compiler, might get us to better results
(probably with less overall development effort) than an evolutionary
approach based on the current code.
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.
>
> Costin
>
Craig
