tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Serack - x3 <gser...@timesthree.com>
Subject Java code generation tomcat JSP's
Date Thu, 21 Sep 2000 13:55:25 GMT
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
(http://developer.java.sun.com/developer/bugParade/bugs/4211181.html) )

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
gserack@timesthree.com
403-569-7012



Mime
View raw message