Java Enterprise in a Nutshell, Third Edition

Chapter 4. JavaServer Pages

In Chapter 3, we looked at Java servlets, J2EE’s primary mechanism for communicating with web browsers. Servlets are a great technology, but they don’t solve every problem faced by web developers, and they introduce a few issues of their own. One major problem is that developing complex HTML-based user interfaces with servlets is time-consuming. Embedding strings of println() statements is tedious and error-prone and requires that pages be assembled by a fully qualified programmer who, just perhaps, should be off doing other things. Configuration is also a problem, although it has been simplified a great deal since the original Servlet API. Adding a new servlet to a web application involves editing the deployment XML file and typically reloading the application or restarting the server.^[18] Changes to a servlet create the same issues, turning rapid prototyping into regular prototyping.

On the design side, servlets can also blend application logic with presentation logic, undoing one of the primary benefits of the client/server architectures that they often replace. In a canonical J2EE environment, where business logic is abstracted into Enterprise JavaBeans or other middleware, this is not much of a concern. But in real life, full J2EE systems aren’t always appropriate. Many applications don’t need the full weight of an application server, and often developers lack the interest or time to create a full J2EE implementation. And even within a J2EE application, ...