See intermixed.
> Date: Thu, 09 May 2002 20:48:27 -0400 (EDT)
> From: Denis Benoit <[EMAIL PROTECTED]>
> Subject: Re: [PATCH] Re: [PROPOSAL] Modification of the code generated by
Jasper2
>
> Good idea, but I think it would be hard to accomplish as presented. Look
again
> at your pseudo-code:
>
> > int state = 0;
> > // try { // 1st try
> > ++state;
> > ...
> > // try { // 2nd try
> > ++state;
> > ;;;
> > // } // end of 2nd try
> > --state;
> > // try { // 3rd try
> > ++state;
> > ;;;
> > // } // end of 2nd try
> > --state;
> > // } // end of 1st try
>
> You'll notice that both state 2 and state 3 have the value 2 assigned to the
> state variable. What is complex here, is that it is hard to find a generic
> way to represent all the states possible. Sometimes the states are nested,
> like the first with the 2nd and 3rd. Sometimes the states follow one another,
> like the second and third.
>
I realized my mistake as soon as I sent it out. :-)
> But there is surely something to do. Suppose we assign distinct values to
> the state variable at each step where we enter a "pseudo try" and a
> "pseudo finally". Then, theoritically, it should be possible to determine
> in the "finallies" method, just by looking at the value of the state variable
> what remains to do. The problem could be to do it in exactly the same order
> that would have been done if the page would have nested try/finally clauses.
>
If we have distinct values for each state, theorectically we can implement
a state transition machine in the finallies. Something like the following.
while (state > 0) {
switch (state) {
case 0: ...
state = 3; break; // goto state 3
case 1:
state = 13; break; // goto state 13
...
case 10: ...
state = -1; break // stop
}
}
This way we can specify any sequence we want. Of course there are various
optimizations that one can do here, but I won't go into them here.
> If we look at what we have to do in the "finallies" method, we have
essentially
> two types of method call. Either the "popBody()" or the "release()" of a Tag.
> I'm certainly not expert enough with the JSP specs to take a decision. Is it
> critical that we call the "release()" of the tags in the proper order, if all
> what's left to do is "release()" calls? What about the popBody()?
>
popBody() simulates popping stacks, and has to be called in order.
> If we could do the "popBody()" calls out of order, say after all the
"release()"
> have been called, then the case of the "popBody()" is easy to deal with. We
> just have to increment a counter for each "pushBody()" calls and decrement
> it after each "popBody()" calls. In the "finallies" method we only have to
> call "popBody()" the number of times the value of the counter. If so, the
> state variable would only to have to represent the different combinations that
> the tags "doStartTag()" have been called and if their respective "release()"
> have been called.
>
Unfortunately we cannot call release() before calling popBody(), because
popBody() may use resources released by release(). (I'll need to check
that).
> I'm a little cautious about "inlining" the "finallies" method, because of
> java's 64K per method limitation. One of the first pass of my test JSP did
> generate over 64K in the _jsp_service method, so it generated an "Invalid
> branch" exception or something named like that. Once I removed a few tags,
> the page worked fine. It's easy to bypass by "JSP include", but some people
> might find the message cryptic (it is!), to determine what's exactly the
> problem. The _jsp_service method can be really long, even without the
> "finallies" being inlined. That's why I had created a new method.
>
There maybe other ways to branch out part of the code in _jspService to
a method. I am considering moving the body of a tag that does not have
scriptlets out; but that's just a thought at this moments.
Even if we do keep finallies, it may worth looking into passing all the
necessary objects as arguments to it, instead of putting them in a Vector,
at least for the case with samll number of states. I think VM spec allows
256 arguments to a method. :-) We want to avoid "unnecessay" codes in
the main flow, but can afford to work harder when exceptions occur.
> Your idea of getting information from the PageInfo is certainly welcome. This
> way we could prevent the creation of the "finallies" method and
> "addTagToVector". We could even replace the Vector by an Array that could be
> allocated to the proper size at the start of the method. It would prevent to
> have to cope with the expansion of a Vector. Your idea of the "state"
variable,
> merit more thought. There may be a way to use it.
>
Collecting information to PageInfo requires a speparate pass prior to
code generation; but is certainly worth looking into.
> What do you think?
>
> --
> Denis Benoit
> [EMAIL PROTECTED]
>
- Kin-man
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
