tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anil K. Vijendran" <>
Subject Re: Java code generation tomcat JSP's
Date Fri, 22 Sep 2000 00:16:06 GMT
There's a couple of things in there that can help you reduce the code size.

There is an init param that stores all the template text in a separate file.
That way the string constants all don't show up in the generated code. I don't
remember the name of the init param, please look it up. Also I did this really
long time back and I'm not sure if every change to Jasper was tested with this
init param on and off. The default is that the template text are emitted as
string constants.

If you don't like the comments that give location info for IDEs and other
generated code readers, you can add another init param which is checked before
emitting the locus info. This should be a very small change.

Otherwise thanks for making a list of things tat could be canged for
performance. I don't work on this stuff anymore but if I do get a spare day or
two and no one beats me to it, I'll try to take care of your the items on your

Garrett Serack - x3 wrote:

> I've run into a couple of snags with Tomcat 3.1, I've got a couple of
> complex JSP pages which are starting to run rather large, and make extensive
> use of in-house custom Tags.
> The Code that Tomcat is generating is MASSIVE. 441k .java / 75k .class file.
> wow.
> I'm starting to run into VerifyErrors on the class itself, after it has been
> compiled.  This behavior has been noted as a bug on Sun's bug tracking
> system. (Bug ID: 4211181 (verifier) VerifyError using custom class loader
> ( )
> Now in a panic effort to solve our problem, we first upgraded Solaris to
> jdk1.3. No help. Then we moved to Tomcat 3.2b4, and the code generation was
> better, and it helped.
> Now I looked at the code Tomcat generates and while 3.2b4 's  is better,
> (less introspection to set properties from tags) It still looks rather
> wasteful.  And there is no object pooling of the tag resources themseleves.
> This is going to lead to a severe problem in scaling apps larger.
> So, I guess my questions are :
> 1. Is anyone looking into the use of taglibs, and the code that is generated
> to use them?  How about adding object pooling into the code to re-use the
> instances of the tags more?
> 2. I've been wondering if the massive amount of try/catches are neccasary in
> the code generation, could this not be done slightly higher up and catch
> with less fine granularity?  This would significantly impact the speed of
> execution and the .class file complexity ( hopefully skirting Bug ID:4211181
> )
> 3. is there a way to make Tomcat not emit the comments into the generated
> java files?  I went thru and stripped out the comments from a couple of the
> files, and they dropped about 130K out of 440K.  I know, the comments don't
> affect code size, and the JSP's don't recompile all the time, so this should
> not affect production speed at all, but I do have to recompile the JSPs tons
> of times a day, and anything I can to to shave off a second or two makes me
> happy.
> 4. There are a large number of identical
>         if( xxx == yyy )
>                 throw new JspException( "really reallyreally reallyreally
> long string");
> type of expressions int the generated code.  With all these potential object
> creations in the code it might be much much more simple to instantiate the
> Exception object at the beginning of the code, and throw it when the fit
> hits the shan.
>         if( xxx == yyy 0
>                 throw thePrebuiltException;
> Much less code in the course of the generated java file...
> Anyhoo, just my 2c + tax....
> Garrett
> Garrett Serack
> Software Development Consultant
> 403-569-7012
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Peace, Anil +<:-)

View raw message