I don't think the overhead of calling a private/final method is very big, especially with hotspot or any decent jit.
If this turns to have an impact, we can turn it on only for pages with many tags, but I think it would be fine for all pages ( without scriptlets ). BTW, given that the logic in a JSP page without scriptlets is quite simple, using a state machine may also be a good solution. I mean saving a pre-processed/binary form of the JSP as data, and using a sort of interpreter. I have big doubts on the benefits of using a compiled form for this kind of data-driven stuff. That's just an idea - it may also work well without even compiling the page to .class for most non-scriptlet pages. Costin On Fri, 24 May 2002, Kin-Man Chung wrote: > The JVM limits the size of a method to less than 65535 bytes. This limit > can easily be reached by a JSP page with 50-80 custom tags, depending > on the javac compiler and the complexity of the tags. The use of > "largefile" option delays reaching the limit a little, but not by much. > That's one of the reasons largefile option is not implemented in jasper 2. > > My proposal to solving this problem is to generate codes for a tag > handler (including its body) to a separate method. This is only feasible > if the tag action element and its body does not include any scripting > elements. The current trend (in the coming JSP1.3) seems to be moving > to scriptless pages, so this is not as restrictive as it appears. > > I don't have a detailed design yet for Generator, but I don't see any > obvious problems. The recent change in flattening out the try/catch > blocks complicates things a little, but they are manageable. > > There is obviously some performance trade-offs. I really don't like > using a compilation option to turn on/off features, especially if it is > used only to get around limitations the users don't care. I think jasper > can make code generation decisions based on the number of tags (both > sequential and nested) in a page. I plan to make experimentation ease > by having parameters (such as number of tags, size of tag body) that can > be adjusted, and hopefully to arrive at a balance between limiting the size > of a method to 64K and some reasonable performance. > > Comments? > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
