JSP Coding Hints

     Java Server Pages (JSP's) are a part of the Java Servlet specification from Sun. Java Servlets and the extension J2EE (Java 2 Enterprise Environment) is a common choice for businesses for many reasons. Servlets are a flexible and broadly supported specification, which have application servers available from a variety of vendors.

     There are a variety of other application servers which use a similar principle to JSP of embedding bits of server-side code in what otherwise looks like a regular HTML file. However, the advantage of JSP is that it uses a multi-purpose, widely-used programming language (i.e. Java). Other application servers such as PHP, Cold Fusion, and TEA use programming languages invented solely for the purpose. Consequently, they have fewer functions and support available to them. One exception is EmbPerl, which uses Perl. Unfortunately, there is very little business support for EmbPerl.

Conventions/Style

     It is a common mantra that you should avoid mixing Java code and HTML markup. This allows markup designers to work on the static content and appearance while Java engineers work on the dynamic content and data processing. However, this principle can be carried too far.

     The purpose of avoiding Java code is to increase readability. The alternatives to putting in Java code (such as custom taglibs) are sometimes less readable than simple code logic. For example, a simple "<% if (condition) { %> ... <% } // end if %>" statement is reasonably clear. A custom tag library, however, is not immediately clear to both the markup designer and a Java engineer. The supposed simplicity of not including code has made the cause more obscure to everyone.

     Any Java which appears in JSP's should be display logic rather than business logic. Business logic includes all details about how raw data is accessed or created. Any database access, file reading, and so forth should be kept separate from the code in JSP's. The JSP's should only contain logic about how to display the data. They should have no idea how the data is stored.

     My simple rules of thumb for putting code in JSP's:

• Data processing should be separated from markup. This can be done by keeping a single block of code at the top of the JSP file, separating the code out into an include file, or by using taglibs. By separating code out into include file or taglib, you can reuse that code for similar pages.
• Display logic can include basic if statements and loop statements. You should give the loop variable a descriptive name. The array or list object should be formed separately in the code.
• Java comments (i.e. "<% // comment %>") are fine for general usage. In fact, one should favor using them over regular HTML comments (i.e. "<!-- comment -->) since they are filtered out by the server. Most comments should not be visible to the end user, although HTML comments can be useful for debugging.

JSP Code Structure

     You should also attempt to standardize how data in beans is accessed. One example of this is an interesting article entitled Transparent Data Pipelines from O'Reilly. This suggests a model where all JSP beans have the same interface so that markup developers only have to learn one interface. The programmers of business logic then make sure that returned objects match that interface.

Exception Handling

     Exceptions in JSP's are more difficult to diagnose than in compiled code. This can be helped by using bean classes or by defining class methods within a JSP (using "<%! ... %>").

     You can deal with exceptions by setting up a central ErrorServlet with its own URL. Then all of your JSP's can reference that URL as their errorPage. Within the ErrorServlet, you can process any of the exceptions and forward the request/response to a real JSP. The JSP can then be decided based on the exception thrown, the user id, or any other parameters.

JSP Template Mechanisms

     A JSP templating mechanism will help to maintain your site by keeping standard look and feel in one place. However, they also add yet another layer of complexity. Possible templating engines include:

• Struts: This looks like a nice templating engine, but needs investigation.
• Cocoon2: This was investigated at an early stage, but it was very slow in performance.

Tag Libraries

     There are a lot of pre-made JSP taglibs out which are available for use. In particular, Jakarta has one that could be quite useful, as they are continually improving and adding to it.

     However, tag libraries are not always optimal in performance, and also may interfere with readability since it requires learning a particular third-party API. For example, it is generally more efficient and readable to use the standard Java Date and Calendar objects as Java code, rather than using the Jakarta datetime JSP tag library.

Optimization

     Specific servlet containers may have different performance considerations.

     For example, some servlet containers may create a new Thread on every request of a JSP. If you can configure your container to instead use a ThreadPool, you can get a significant performance increase. This can be set in server.xml by defining the variables "max_threads", "max_spare_threads", and "min_spare_threads".

     For 3.x Tomcat engines, you should make sure that you are using the Ajp13 connector. Ajp13 performs much better than the 12 connector. You will still need the Ajp12 connector since it controls stopping tomcat, but user requests should be hitting Ajp13.