Bug 24846 - Quantity of org.apache.jasper.runtime.JspRuntimeLibrary.* usage triggers javac bug
Summary: Quantity of org.apache.jasper.runtime.JspRuntimeLibrary.* usage triggers java...
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Jasper (show other bugs)
Version: 5.0.14
Hardware: All All
: P3 major with 1 vote (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2003-11-20 04:25 UTC by Jess Holle
0 users


Description Jess Holle 2003-11-20 04:25:13 UTC
In Tomcat 5.0.14, for large JSP files with many includes, etc (producing a 
94K .java file in this case), so many 
org.apache.jasper.runtime.JspRuntimeLibrary usages are generated that javac 
fails and reports an error stating "cannot resolve symbol".

The symbol is "apache" and the location is "class java.lang.String" in a use of 
response "/some/path/someJsp.jsp", out true).  Identical lines preceding this 
one did not produce compile complaints.

This error is reproducible with javac from the command line with Java 2 
v1.4.2_02 and 1.3.1_09 (the only 2 SDKs I have on the given system).

The error goes away if one alters the source to import 
org.apache.jasper.runtime.JspRuntimeLibrary and use "JspRuntimeLibrary..." 
rather than the fully qualified package name!

I understand the importance of avoiding namespace pollution, but being able to 
rely on JSP pages compiling is of higher importance than possible collision 
with "JspRuntimeLibrary"!  I also understand this is Sun's bug, but a 
workaround in Jasper is a lot faster/easier than getting a javac bug fixed and 
available on all platforms.

I would like to suggest adding org.apache.jasper.runtime.JspRuntimeLibrary to 
the list of imports in PageInfo's constructor (i.e. not as a standard import -- 
as it certainly is not but as an omni-present one all the same) and changing 
Generator to use "JspRuntimeLibrary" without package name qualifiers.  If this 
change cannot be made in Tomcat 5.0.15 I'll be patching it into our packaging 
thereof but I believe it would be a very good idea to make this patch to 5.0.15 
for everyone's sake!  [The alternative is for Tomcat 5.0.x to get a reputation 
as not being robust in the face of large JSP files -- even if javac is actually 
at fault.]
Comment 1 Remy Maucherat 2003-11-20 09:47:27 UTC
This will not be fixed (as you said, it is not a Jasper issue, and I'm almost
certain the spec mandates no imports outside of a small list). Besides, there is
a significant amount of other compilers which can be used by Ant, so this
shouldn't be a real issue.
You should precompile your application, BTW.

About the last sentence, Tomcat is not completely reliable for large JSP files
anyway (no compliant JSP compiler can be, AFAIK), because of Java limitations to
method code size.
There may also be an easy workaround: disable tag pooling.

We'll refer to your big report for further comments if needed, and to mark
others as duplicates.
Comment 2 Jess Holle 2003-11-20 15:31:13 UTC
Thanks for the ernest reply Remmy.

I can understand your position -- and it makes sense from a spec compliance and
"let's not do further hacks to workaround javac" perspective.

I guess I'll just be patching my own Tomcat with every upgrade (as I do with
every Apache upgrade anyway).
Comment 3 Remy Maucherat 2003-11-20 15:37:08 UTC
There are, IMO, much better solutions: you could for example use Eclipse Java
compiler (called EDT, I think) instead (Ant supports it, so Jasper does too). It
seems way faster than javac, without any disadvantages.
Comment 4 Jess Holle 2003-11-20 15:44:49 UTC
Are there any non-native (i.e. Java-based) compilers that I can distribute
freely, will work on Windows, Solaris, HPUX, AIX, and Linux and are as
1.4.x-compatible as javac, yet have fewer compiler bugs?  Is the Eclipse
compiler such a beast?

Excuse me for my ignorance.  If javac is so bad in general, is the Tomcat group
distributing an alternative "out-of-the-box"?