Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

More JSP best practices

JSP advancements ease development of standardized, highly maintainable JSP-based applications

By Dustin Marx, JavaWorld.com, 07/25/03

Page 2 of 6

Employ JSP code conventions

It is prudent on any project, using any language, to follow coding standards and conventions to improve development, maintenance, and testing of your software. Reading another developer's code is often neither simple nor enjoyable. Conversely, if all developers followed the same naming and other conventions, code review and maintenance would be easier for everyone involved, including the original developer.

Sun Microsystems has recently assisted organizations trying to create these conventions by making the document "Code Conventions for the JavaServer Pages Technology Version 1.x Language" freely available (see Resources). If your organization does not already follow JSP code conventions, I recommend using this document as a starting point. You can either use it as-is or build your own conventions around it.

Use appropriate scope for bound objects

The JSP specification supports four levels of scope (application, session, request, and page) that you can associate with objects created explicitly for JSPs to use. Because objects bound to any of these four scopes consume memory and, in some cases, require cleanup, it is best to use the appropriate scope for the task you want to accomplish.

Application scope

Application scope is the broadest scope and should only be used when necessary. You can create objects bound at application level in JSPs that are not session-aware, so application scope is useful for storing information when using these types of JSPs. You can also use application-bound objects to share data among different sessions of the same application. When you no longer need objects bound to an application, you should explicitly remove them to free up memory resources.

Session scope

In my experience, session scope is more commonly used than application scope. Session scope allows you to create and bind objects to a session. You must create objects bound to the session in session-aware JSPs and make them available to all JSPs and servlets in the same session. Session scope is often used for managing security credentials and for managing state among multiple pages (such as in a Web-based wizard). As with application scope, objects bound to session scope should be explicitly removed when no longer needed. Also, I typically make classes serializable if I intend to bind their instantiations to the session scope.

Request scope

I use request scope most often for binding created objects. Objects created and bound to request scope are available to pages in that same request. These objects are automatically released from memory when request processing completes. This is advantageous because explicit cleanup is not required and there is less risk of burdening the system with needless memory consumption.

Page scope

You should use page scope for objects created only for the current page. Like request scope, the page scope does not require explicit removal of created and bound objects. I rarely use page scope in my JSP applications, but it is the <jsp:useBean> action's default scope.

Which scope to use?

You should carefully choose scope for created objects to ensure efficient memory use and management. In general, I typically begin with request scope in my designs and then evaluate whether I need a broader scope for my created objects.

Carefully manage session scope

As stated in the best practice above, use session scope only when necessary and be sure to explicitly remove objects from session scope when you no longer require session access to these objects. For any JSP in which you don't use a session-bound object, you can set the page directive's session attribute to false to avoid the overhead involved with session management. However, I find few Web applications that don't need session support. Instead, I typically use session support for security mechanisms and other Web application needs. Even though a session expires after a configurable amount of time, it is best to invalidate these sessions explicitly when you no longer need them rather than rely exclusively on the automatic timeout mechanism.

Take advantage of JSTL

One of the most significant advancements for JSP developers has been the introduction and adoption of JSTL. Normally referred to as JSTL, it is also referred to as JSP Standard Tag Library. Note the T in JSTL stands for Tag rather than Template.

JSTL: A brief background and overview

In my earlier article, I recommended that JSP developers use available custom tag libraries rather than reinvent the wheel. Many commercial and open source custom tag libraries are available, but their one drawback requires developers to write JSPs to use those libraries in ways mandated by those custom tags. The advent of JSTL has addressed this downside by providing standard interfaces to the custom tags that perform many basic functions JSP developers need. Different vendors might implement the JSTL tags differently, but developers don't need to know about the differences in implementation. If a JSP developer writes his pages or documents to use JSTL tags, the JSP page or document should work with any JSTL implementation.

Plenty of good books and online resources exist for learning about JSTL (see Resources). Here, I briefly touch on JSTL's general advantages and features.

JSTL's advantages

In short, JSTL offers all the benefits of any publicly available custom tag library, but also provides the additional benefit of a standardized tag API. JSTL facilitates highly maintainable and transferable pages or documents. I list JSTL's specific advantages:

• JSTL allows for tag-based iteration, conditionals, and other functionality previously implemented with Java scriptlets embedded directly in the JSP either with homegrown custom tags, a nonstandard tag library, or by abandoning the JSP in favor of a servlet.
• JSTL tag interfaces (tag name, optional and required attributes, etc.) are standardized so that, once written, JSPs using these tags should work with any JSTL tag implementation.
• JSTL takes advantage of expression language (EL) syntax.
• Writing custom tags requires more effort and experience than many JSP development tasks. JSTL addresses this in two ways: First, as mentioned above, JSTL handles many common needs for custom tags. Second, JSTL provides mechanisms that make writing your own custom tags easier, especially if you want your own custom tag libraries to support the EL.

Specific JSTL features and advantages

This section briefly summarizes some advantages of using three of the four available JSTL custom tag libraries and some reasons not to use the JSTL database access library. I also discuss the advantages of using EL in this section.