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 6 of 6

JSP documentation generation for JSP documents

Because neither JspDoc nor JSPDoc currently support JSP documents, I take advantage of JSP documents' XML-compliance to perform Javadoc-like documentation generation. Using an XSLT stylesheet, you can easily create HTML-based pages documenting the XML-compliant JSP documents. No custom parsing is required because any of the standard translator tools (such as Xalan) will handle this process when the source document is a valid XML document. See the "JSP Documentation with XSLT" sidebar for such a stylesheet example.

Precompile your JSPs, even in development

When you execute a JSP by typing its URL into the browser, the JSP goes through much processing before being rendered to the browser as HTML. Because of all this processing, JSPs take considerably longer to execute the first time they are accessed than they do on later accesses. While most developers understand the importance of compiling these JSPs before making them available to the public, it is also useful in development to precompile JSPs before rendering them as HTML.

You can include the precompilation process in the regular code build, and compile JSPs at the same time as their associated JavaBeans, custom tag handler classes, and other associated classes and servlets. This lets you run a single build and keep most of the waiting time confined to one period. Because developers are often distracted as they wait for compilation, it can be advantageous to do all the compilation at once rather than compile each JSP as it's requested.

Precompilation can catch parser problems and other translation-time problems of pages that typically require several steps to reach. This is advantageous because it prevents the developer from navigating through multiple pages to get to the point where the relevant page is requested. If you use JSP documents, the precompilation step typically verifies that the JSP document is well formed.

Another advantage of precompilation is that you can include your JSPs' compiled versions in the Web archive (war) file rather than delivering the actual JSP source code in the war file. When JSPs are precompiled and translated for inclusion in the war file, they are included as .class files with vendor-specific naming conventions.

JSP precompilation is available with most modern Java 2 Platform, Enterprise Edition (J2EE)/Java IDEs. The major Web servers also support JSP precompilation, though they typically support it with nonstandard commands or interfaces. Most Web servers provide a command line-based JSP precompiler that you can integrate with scripted builds.

Organize files and directories

The following are additional techniques that make JSP development and maintenance easier and more efficient:

• Organize the Web context root directory
• Organize the WEB-INF directory with appropriate subdirectories
• Identify JSP fragments with the .jspf extension
• Use IDE, Ant, or other automated tools

Some of these techniques can benefit from the use of coding conventions as described earlier in this article.

Organize the Web context root directory

You can build Web applications by putting nearly all the Web application's content files directly in the Web context root directory. This is the directory in which the WEB-INF subdirectory normally resides. I recommend organizing this directory with subdirectories such as a jsp directory, an html directory, a css directory, an images directory, and so forth. For the simplest applications, this organization is probably more hassle than it's worth, but it eases comprehension and maintainability of large Web applications.

Organize the WEB-INF directory

Tag libraries are a valuable resource in JSP development. Large Web applications might consist of several tag libraries such as JSTL tag libaries, Struts tag libraries, and other tag libraries. Instead of inundating the WEB-INF directory with tag library descriptors, I prefer to create a tld subdirectory under WEB-INF and place the tag library descriptors there. You can do this to existing Web applications without harming the existing JSPs as long as the mapping in the web.xml file is edited to account for the new tld subdirectory. The web.xml file, the classes directory, and the lib directory are standard components in the WEB-INF directory. Moving the tag library descriptor files into their own directories reduces WEB-INF directory clutter.

Identify JSP segments with the .jspf extension

Known as JSP segments in more recent JSP specifications and JSP fragments in older specification versions, .jspf files are incomplete JSPs designed for inclusion in an encompassing JSP. The JSP specification encourages the use of naming conventions to help differentiate between outer (or top-level) JSPs and these JSP fragments/segments. Although the specification does not require it, the most common method of making this differentiation is to name complete and top-level JSPs with the traditional .jsp extension and the JSP fragments/segments with the .jspf extension. I also suggest keeping top-level JSPs in a separate subdirectory from the JSP fragments.

Use IDE, Ant, or other automated tools

IDEs can speed development and deployment times and reduce typos and other minor errors. Numerous IDEs are now available with J2EE development tools and wizards. These IDEs are being delivered with integrated frameworks such as Struts and JSTL tag libraries.

Ant is the defacto standard for building and deploying Java and J2EE applications. Ant allows enough flexibility to build and deploy virtually anything you want, but also provides specific support for building and deploying war and ear files. Many IDEs now have Ant-integration support. When I don't have access to an IDE, I consider Ant indispensable. Other tools that automate the building and deployment process can provide the same advantages of Ant, but Ant's most significant advantage may be its cost (freely available as open source) and its wide support and userbase.

I also want to mention Apache Maven as a useful product to consider for total Java project management.

Reconsider nonspecification-compliant features

Web servers occasionally provide vendor-specific features useful in production because they improve performance, increase security, or offer other advantages. In some cases, using these vendor-specific features is justified because the advantages outweigh the risks. However, it is important to be aware of the risks associated with vendor-specific features and to choose specification-compliant features over vendor-specific ones when their benefits are roughly equal. Keep in mind that not all features are specifically called out in the specification and, in that case, any vendor's implementation will be proprietary.

Technical dependencies do not always make vendor-specific features potentially risky. Custom tag libraries provided by Web server vendors may work on any Web server that fully supports custom tags, but you must be wary of licensing issues in these cases.

This best practice's significance depends on the likelihood of switching Web servers. When I am not using Tomcat as my Web server, I occasionally deploy my J2EE-based Web applications against this reference Web server implementation to verify specification compliance. Keep in mind that using vendor-specific features can be risky even if you stay with the same vendor for an extended time period. This is because the rapidly improving J2EE specifications often address issues in a standard way after vendors have made the features popular in their own proprietary way. In those cases, the vendors typically move to the standardized approach with future product versions.

Use XHTML syntax

In "JSP Best Practices," I recommended using HTML best practices in your JSPs. More specifically, I now find that the XHTML specification offers the most useful version of HTML tag syntax in authoring JSP documents. XHTML provides for HTML syntax that is entirely XML compatible, making it the perfect HTML tag syntax for developing XML-compliant JSP documents. Even JSP page authors will likely find it advantageous to use XHTML tag syntax in their JSPs.

To be completely XML-compliant, XHTML tag syntax must follow stricter rules than standard HTML tag syntax. The stricter requirements and the differences between standard HTML and XHTML tags are outlined in the World Wide Web Consortium's XHTML 1.0 pages.

It only gets better

JSP technology was originally created to simplify flexible Web development. Recent advancements such as JSTL have continued this trend. Even improvements in the servlet specification (such as filters) have strengthened JSP development convenience. The advancements in the JSP and servlet specifications, along with the advent of new development tools and sharing of JSP coding standards and conventions, have made highly maintainable JSP development easier than ever.

About the author

Read more about Enterprise Java in JavaWorld's Enterprise Java section.