Use servlets and JSP judiciously

All the sizeable Java EE applications use a framework like Struts, Java Server Faces etc where the controller is invariably a servlet object. The key disadvantage of servlet technology is that even a minor modification to static content requires changes to the Java code to output HTML. The JSP overcomes this shortcoming by combining HTML and Java. The static part can be pure HTML where as the dynamic aspect can be managed by including code in JSP tags for directive, scripting and action. (Incidentally, JSP tag libraries and JSP expression language are preferred vehicles for including Java code into JSP nowadays). A combination of JSP and servlets provides horses for courses. Historically, the servlet technology is the forerunner to JSP for dynamic content and, unsurprisingly, each JSP page translates to servlet code prior to execution. Thus it is common to use both servlet and JSP technologies in applications as servlets are inevitable but JSP provides convenience, simplicity and ease of development. It also facilitates segregation of responsibilities amongst development teams as the web designers can focus on rather static presentation aspects in JSP whilst the Java developers concentrate on processing logic in servlets and custom tag libraries. This can be enforced by declaring some JSP pages as scriptless in the deployment descriptor of the application. Also in the prevalent model-view-controller architecture, the servlets act as controller whilst the JSP pages provide views. Both technologies are capable of invoking each other so we can focus on the best solution for the task at hand.

However, in the real world to create a truly interactive web application we will go a step further and use Java Server Faces (JSF) technology which builds on these two technologies. With JSF2.0, it is even deemed that JSP is deprecated for creating views.