The Problems with JSP (JavaServer Pages)

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

By now almost everyone using servlets has heard about JavaServer Pages (JSP), a Sun-invented technology built on top of servlets. Sun has done a marvelous job promoting JSP as a way to get HTML out of servlet code, speeding Web application development and improving Web page maintenance. In fact, the official "Application Programming Model" document published by Sun has gone so far as to say, "JSP technology should be viewed as the norm while the use of servlets will most likely be the exception." (Section 1.9, December 15, 1999, Draft Release) This paper evaluates whether that claim is valid.by comparing JSP to another technology built on servlets: template engines.

The Problem with Straight-up Servlets

In the beginning, servlets were invented, and the world saw that they were good. Dynamic Web pages based on servlets executed quickly, could be moved between servers easily, and integrated well with back-end data sources. Servlets became widely accepted as a premiere platform for server-side Web development.

However, the commonly-used simple approach to generating HTML content, having the programer write an out.println()call per HTML line, became a serious problem for real servlet use. HTML content had to be created within code, an onerous and time consuming task for long HTML pages. In addition, content creators had to ask developers to make all content changes. People searched for a better way.

Along Comes JSP

Around this time JSP 0.90 came along. With this new technology you could put snippets of Java code inside your HTML, and the server would automatically create a servlet from the page. This helped quite a lot. There was no attempt to hide the Servlet API; JSP was considered a "cheap" way for a Java programmer to write a servlet. All the HTML code could be included directly without out.println() calls and page creators could make changes to the HTML without serious risk of breaking the Java code.

But having artists and developers working on the same file wasn't ideal, and having Java inside HTML proved almost as awkward as having HTML inside Java. It could easily create a hard to read mess.

So people matured in their use of JSP and started to rely more on JavaBeans. Beans were written to contain business logic code needed by the JSP page. Much of the code inside the JSP page could be moved out of the page into the bean with only minimal hooks left behind where the page would access the bean.

More recently, people have started to note that JSP pages used this way are really a "view". They're components used to display the results of a client request. So people thought, Why submit a request directly to a "view"? What if the targeted "view" isn't the proper view for that request? After all, many requests have several possible resulting views. For example, the same request might generate a success page, a database exception error report, or a required parameter missing error report. The same request might also generate a page in English or a page in Spanish, depending on the client's locale. Why must a client directly submit its request to a view? Shouldn't the client make a request to some general server component and let the server determine the JSP view to return?

This belief caused many people to adopt what has been called the "Model 2" design, named after an architecture laid out in the JSP 0.92 specification and based on the model-view-controller pattern. With this design, requests are submitted to a servlet "controller" that performs business logic and generates an appropriate data "model" to be displayed. This data is then passed internally to a JSP page "view" for rendering, where it appears to the JSP page like a normal embedded JavaBean. The appropriate JSP page can be selected to do the display, depending on the logic inside the controlling servlet. The JSP page becomes a nice template view. This was another improvement.and where many serious developers stand today.

[ Onto Next 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.