Bug 50895 - JSP compiler initializes classes during compile which can result in failures
Summary: JSP compiler initializes classes during compile which can result in failures
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Jasper (show other bugs)
Version: 6.0.32
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2011-03-08 15:27 UTC by Andy Wang
Modified: 2011-04-18 09:57 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Andy Wang 2011-03-08 15:27:00 UTC
The fix for Bug 49555 adds the following code call:

                clazz = Class.forName(className, true, tccl);

The 2nd argument (initialize) is set to true resulting in it attempting to initialize the class.  This can result in compilation failures if the class has ugly static initializer requirements.  It can also increases the time and memory footprint of compilation as the classes.

I think for the purposes of the getCanonicalName() call, the second argument should be set to false to prevent initialization of the class in question.
Comment 1 Mark Thomas 2011-03-08 17:30:09 UTC
Initialisation has to happen at some point. If it doesn't happen at compilation it will happen at first use very shortly afterwards. Failing early is actually better. Therefore I am closing this as INVALID.

If you have a test case that currently fails that changing initialize to false will allow to work then please re-open this issue and attach the test case.
Comment 2 Andy Wang 2011-03-08 17:42:39 UTC
We have a tag that contructs a class that has runtime dependencies in it's constructor.

When using the Jspc ant task to compile, these runtime dependencies don't exist.  However, when the class is actually called during runtime (i.e. within a running tomcat instance) the runtime requirements exist and are fine.

I can't provide you our usecase because it's dependent on many many layers of our code, but I can easily provide you with a contrived usecase of a jsp file that will compile and load fine when tomcat is running but will not when using the out of band Jspc ant task to perform a precompile if you wish.

I think this is a valid scenario.
Comment 3 Andy Wang 2011-03-08 18:05:16 UTC
I haven't coded this up, here's a simple example:

my.jsp page that contians the following

MyClass class = new MyClass();

MyClass contains the following code

 static {
     File file = new File("/path/to/file/that/only/exists/at/runtime");
     if (!file.exists()) {
        throw new Exception();

my.jsp is perfectly valid to precompile in this case, but precompilation using the Jspc ant task will fail because the instantiation of MyClass will fail due to the file that doesn't exist.

While this is a horrible example and I won't argue the coding pattern isn't ideal, we have a couple of cases where a jsp page relies on a class that has a static constructor that has runtime dependencies.  As a result, we are unable to precompile the jsps without patching tomcat and making the initialize flag false.

The other thing.  All of our JSPs takes 96 minutes to pre-compile with 6.0.32.
Took about an hour with 6.0.28.  With the initialize set to false it's somewhere in between.  The initialization step of some of our classes with  complicated static initializers can be time consuming.
Comment 4 Mark Thomas 2011-03-09 08:52:28 UTC
Yep, that is a really ugly example but I take the point.

Fixed in 7.0.x and will be included in 7.0.11 onwards.
Comment 5 Andy Wang 2011-03-09 14:53:44 UTC
Thanks.  Any plans to put this into 6.0?  We're patching 6.0.32 to deal with this, so not a huge deal.  Just want to know if we should expect to continue maintaining this change ourselves for 6.0.
Comment 6 Mark Thomas 2011-03-09 15:18:26 UTC
It will go into 6. I have my hands full with 7 at the moment but someone (maybe me, maybe someone else) will propose this for backport.
Comment 7 Mark Thomas 2011-03-10 08:21:38 UTC
Proposed for 6.0.x
Comment 8 Mark Thomas 2011-04-18 09:57:13 UTC
Fixed in 6.0.x and will be in 6.0.33 onwards.