Bug 43702 - Class Files Have Unnecessarily Long Names when Using SimpleTags
Class Files Have Unnecessarily Long Names when Using SimpleTags
Status: RESOLVED FIXED
Product: Tomcat 5
Classification: Unclassified
Component: Jasper
5.5.24
PC Windows XP
: P2 normal (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2007-10-26 03:17 UTC by D Gardner
Modified: 2007-11-29 14:56 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description D Gardner 2007-10-26 03:17:17 UTC
I have been using Tomcat 5.5.7 (though I have checked this on the
latest 5.5 and 6.0 releases too) and had some problems with very
long class file names when using the SimpleTag interface for a
custom tag in a JSP document (the XML representation).

From my reading of the code in Jasper, and my observation of the files
on my disk, if I have a JSP file "WebContent/mypages/MyPage.jspx",
then a class file named "work/org/apache/jsp/mypages/MyPage_jspx.class"
will be generated by Jasper.

If I use the SimpleTag interface for one of my custom tags on that
JSP, a "helper" class (an inner class of the "MyPage_jspx" class) is
also generated. The naming convention appends "Helper" to the "outer"
class name to create the inner class name resulting in a class file
named "work/org/apache/jsp/mypages/MyPage_jspx$MyPage_jspxHelper.class".

As there is only one "helper" class required, it could just be named
"Helper", instead of "MyPage_jspxHelper". The "outer" class provides
a namespace that is duplicated unnecessarily in the name of the inner
class. Another alternative would be to generate this as an independent
class instead of an inner class (they could reside in the same source
file).

This may not seem to be a particularly important issue, but it becomes
a real problem if the name of the JSP is very long. We generate JSP
files from other sources that often use very long names (the names
are chosen by our customers, so we do not have a lot of control over
how long they can get). We have recently started to use the SimpleTag
interface to try to reduce the size of the Java classes generated by
Jasper (the generated code is more compact, as there is less code needed
to handle return values, etc.) However, we quickly found that if a
developer's project directory was deeply nested on the file system
(i.e., the path to the "work" directory) and/or the JSPs had long names
(some names were as long as 96 characters) that the filesystem path
length limit on Windows was exceeded and we got "class not found"
errors from Tomcat at run-time for classes that clearly existed on the
filesystem. I have seen these errors before in other circumstances and
they are caused when the path length limit is exceeded.

A trivial change to the Jasper code generator to avoid replicating the
name of the "outer" class in the name of the inner "helper" class would
go a long way to alleviating this problem. I cannot think of any reason
why this would not be a useful improvement to Jasper. It is a one line
change to the constructor of the "org.apache.jasper.compiler.Generator"
class where the FragmentHelperClass object is created (and probably in
some other area where references to this helper are generated into the
servlet code).

Other improvements to the compactness of the generated code could also
be made by more extensive use of "import" statements, but that would
probably not have any effect on the size of the ".class" file after
compilation (or would it?).

For our part, we have had to stop using the SimpleTag interface for
our custom tags, and have to start investigating a way of truncating
long JSP file names to avoid being caught out by Jasper's verbosity
and the Windows path length limit.

Should I report this issues separately against Tomcat 6?
Comment 1 Mark Thomas 2007-10-30 19:18:18 UTC
I have proposed a patch for tc6. If accepted, I'll propose a backport to 5.5.x
Comment 2 Mark Thomas 2007-11-27 15:04:54 UTC
Fixed in trunk and 6.0.x. Proposed for 5.5.x.
Comment 3 Mark Thomas 2007-11-29 14:56:24 UTC
Fixed in svn for 5.5.x. Will be in 5.5.26 onwards.