The Problems with JSP (JavaServer Pages)

Page III

By Jason Hunter - Chief Technology Officer, K&A Software

Problem #4: Lousy Looping

Looping is overly difficult in JSP. Here's the JSP code to iterate over a vector of ISP objects printing the name of each:

<%
Enumeration e= list.elements();
while (e.hasMoreElements()){
out.print("The next name is");
out.println(((ISP)e.nextElement()).getname());
out.print("<br>");
}
%>

Someday there will be custom tags for doing these loops. And custom tags for "if" checks too. And JSP pages may look like a grotesque Java re-implemented with tags. But meanwhile, the WebMacro loop is already quite nice:

#foreach $isp in $isps {
The next name is $isp.Name <br>
}

The #foreach directive could be replaced by a custom #foreach-backwards directive fairly easily as well if such a thing were necessary.

Will custom tags really solve this problem? Probably not. Here's a possible <foreach> tag.

<foreach item="isp" list="isps">
The next name is <jsp:getProperty name="isp" property="name"/>
</foreach>

Which would a graphics artist prefer?

Problem #5: Useless Error Messages

JSP page syntax errors can cause surprisingly odd and useless error messages. This is due to the fact the page is transformed into a servlet and then compiled. Good JSP tools can help narrow down errors to likely syntax error locations, but even the best of tools will probably have problems making all error messages meaningful. Some errors will just be impossible for tools to diagnose, due to the transformation.

For example, assume a JSP page needs to set a title common across all pages. What's wrong with the following?

<% static String title = "Global title"; %>

Well, the Tomcat reference implementation for JSP says this is wrong:

work/%3A8080%2F/JC_0002ejspJC_jsp_1.java:70: Statement expected.
static int count = 0;
^

This cryptic error is trying to say that scriptlets like the above are placed inside the _jspService() method and static variables aren't allowed inside methods. The syntax should be <%! %> . Page designers won't recognize this error, and programmers likely won't either without looking at the generated source. Even the best tools probably won't be much help with errors such as these.

Assuming all the Java code could be moved out of the page, that still doesn't solve this problem. What's wrong with this expression that prints the value of count?

<% count %>

The Tomcat engine says:

work/8080/_0002ftest_0002ejsptest_jsp_0.java:56: Class count not found in type declaration.
count
^
work/8080/_0002ftest_0002ejsptest_jsp_0.java:59: Invalid declaration. out.write("\r\n");

In other words, there's an equal sign missing. It should be <%= count %>.

Because a template engine can operate directly on the template file without any "magical" translation to code, it's far easier to properly report errors. To use an analogy: When commands are typed into a command line Unix shell written in C, you don't want the shell to create a C program to execute the command. You want the shell to simply interpret the command and behave accordingly, with direct error messages when necessary.

Problem #6: Need a Compiler

JSP requires a compiler be shipped with the Web server. That's problematic, especially since Sun doesn't give away the tools.jar library containing their javac compiler. Web servers can package an outside vendor's compiler such as IBM's jikes; however, such compilers generally don't work on all platforms and (being written in C++) aren't much help to a pure-Java Web server. JSP has a pre-compile option that can help some here, although that's a less than elegant solution.

Problem #7: Wasted Space

JSP consumes extra hard drive space and extra memory space. For every 30K JSP file on the server there must be a corresponding larger-than-30K class file created. This essentially doubles the hard drive requirements to store JSP pages. Considering how easily a JSP file can <%@include> a large data file for display, this becomes a real concern. Also, each JSP's class file data must be loaded into the server's memory, meaning the server may eventually store the entire JSP document tree in memory. A few JVMs have the ability to remove class file data from memory; however, the programmer generally has no control over the rules for reclaiming and for large sites the reclaiming probably won't be aggressive enough. With template engines there's no need to duplicate the page data into a second file, so hard drive space is spared. Template engines also give the programmer full control over how templates are cached in memory.

There are also some downsides to using a template engine:

[ Onto Next Page]
[ Previous Page]

About the Author

Jason Hunter works as the Chief Technology Officer of K&A Software, where he specializes in Java training and consulting. He is author of Java Servlet Programming (O'Reilly) and publisher of the Web site http://www.servlets.com. He belongs to the working group responsible for Java Servlet API development and has made significant contributions to the Servlet API and reference implementation. He also writes columns for JavaWorld and speaks at conferences such as JavaOne, Software Development, Web Design & Development, and the SIGS JavaExpo.

Jason graduated summa cum laude from Willamette University (Salem, Oregon) in 1995 with a degree in Computer Science. After graduation, he worked at Silicon Graphics in Mountain View, CA, for several years, where he was responsible for developing (and breaking) all sorts of Web technologies.

TechMetrix Research is a technically focused analyst firm focused on e-business application development needs. Based in Boston, Mass., the firm publishes comparison reports and product reviews designed to aid enterprises with decision making and to keep pace with the fast-moving e-business market.

TechMetrix is a U.S.-based subsidiary of SQLI, a European company that offers on-site development services to international organizations. SQLI specializes in e-business project development.