Introduction
The Servlet technology and JavaServer Pages (JSP) are the two main technologies for developing Java Web applications. When first introduced by Sun Microsystems in 1996, the Servlet technology was considered superior to the reigning Common Gateway Interface (CGI) because servlets stay in memory after they service the first requests. Subsequent requests for the same servlet do not require instantiation of the servlet’s class, therefore enabling better response time.
The problem with servlets is it is very cumbersome and error-prone to send HTML tags to the browser because all HTML output must be enclosed in String objects, such as in the following code.
PrintWriter out = response.getWriter();
out.println("<html><head><title>Testing</title></head>");
out.println("<body bgcolor=\"#ffdddd\">");
...
This is hard to program and even small changes in the presentation, such as the page’s background color, will require the servlet to be recompiled.
Sun recognized this problem and came up with JSP, which allows Java code and HTML tags to intertwine in easy to edit pages. Any change does not require recompilation. Automatic compilation occurs the first time a page is called after it is modified. Java code in JSPs is called scriptlet.
Even though mixing Java code and HTML seems practical at first thought, it is actually not a good idea. This is the reason the designers of JSP allowed developers to write business logic in Java classes and call the methods in these classes from JSPs. Mixing Java code and HTML in JSPs is considered bad for the following reasons:
- Interweaving Java code and HTML results in hard to read and hard to maintain applications.
- Writing code in JSPs diminishes the opportunity to reuse the code. Of course, you can put all Java methods in a JSP and include this page from other JSPs that need to use the methods. However, by doing so you are moving away from the object-oriented paradigm. For one thing, you lose the power of inheritance.
- It is harder to write Java code in a JSP than to do it in a Java class. Let’s face it, your IDE is designed to analyze Java code in Java classes.
- It is easier to debug your code if it is in a Java class.
- It is easier to test business logic that is encapsulated in a Java class.
- Java code in Java classes is easier to refactor.
In fact, separation of business logic (Java code) and the presentation (HTML tags) is such an important issue that the designers of JSP have been trying to encourage this practice right from the first version of JSP.
In JSP 1.0, the designers of JSP enabled you to use JavaBeans to encapsulate Java code, therefore separating code and presentation and promoting code reuse. A JavaBean is basically a Java class. You can use
Unfortunately, JavaBeans do not provide a perfect solution to the problem of code and presentation separation. With JavaBeans, method names must follow the JavaBean naming convention, resulting in occasionally clumsy names. Also, you cannot pass arguments to methods without resorting to scriptlet.
To make code and HTML tags separation easier to accomplish, JSP 1.1 defines custom tag libraries, which is more flexible than JavaBeans. The problem is, custom tags are hard to write and the custom tags in JSP 1.1 had a very complex life cycle.
To alleviate the problem with writing custom tags for developers who want to separate code from presentation, an effort was initiated to provide tags with specific common functionality. These tags are compiled in a set of libraries named JavaServer Pages Standard Tag Libraries (JSTL). For example, JSTL has tags for manipulating scoped objects, iterating a collection, performing conditional tests, parsing and formatting data, etc.
Despite the JavaBeans, custom tags, and JSTL, many people still use scriptlet in their JSPs for the following reasons.
- Convenience. It is very convenient to put everything in JSPs. This is okay if your applications are very simple applications consisting only one or two pages and will never grow in complexity.
- Shortsightedness. Writing code and HTML in JSPs seems to be a more rapid way of development. However, in the long run, there is a price to pay for building your application this way. Maintenance and code readability are two main problems.
- Lack of knowledge.
In addition, in a project involving programmers with different skill levels, it is even harder to make sure all Java code goes to Java classes. Even a brilliant architect would have a headache if he had to watch over all his programmers.
To make scriptlet-free JSPs more achievable, JSP 2.0 added a feature that allows software architects to disable scriptlet in JSPs, thus enforcing the separation of code and HTML. So, if the architect is knowledgeable enough, the developers will have to resort to JavaBeans, custom tags, JSTL, and other libraries for business logic implementation. On top of that, JSP 2.0 provides a simpler custom tag and allows tags to be built in tag files, if effect providing a simpler way to write custom tags.