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 org.apache.jasper.runtime.JspRuntimeLibrary.include(request 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.]
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.
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).
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.
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"?