- Getting Started with Servlets
- The Anatomy of a Servlet
- Sending a Response to the Browser
- The HttpServlet Class
- Choosing Between Java Server Pages and Servlets
Choosing Between Java Server Pages and Servlets
Although you've just barely scratched the surface of JSP and Servlets, now is a good time to talk about when to use servlets, when to use JSP, and when to use both. To make such decisions, you need to weigh the advantages and disadvantages of each. Remember, too, that because Java Server Pages are translated into servlets, they can't be all that different when you get right down to it.
The Advantages and Disadvantages of JSP
The biggest strength of JSP is that it looks like HTML (or XML or whatever kind of content you are generating). You can give a JSP to someone who is familiar with HTML and expect that person to be able to make changes in a fairly short amount of time. It is also quite obvious what the HTML will look like when it is sent to the browser. It is not always so obvious when the HTML is generated by Java code.
An add-on to this strength is the fact that people who are weaker with Java can use Java Server Pages. You don't need to know too much Java to do at least basic things with JSP. You don't even need to know how to declare a Java class. As vendors begin to support other languages with JSP (some already support JavaScript) you will have people who don't even know Java writing Java Server Pages!
A much more subtle advantage of JSP, one that you have not really encountered yet, is that when the JSP is turned into a servlet, that servlet is automatically loaded into the servlet engine. When the JSP changes, its corresponding servlet is automatically regenerated and reloaded. When you are doing rapid development, it's great to be able to make quick changes and see them without having to restart the server. If you make a lot of changes to a lot of files, you don't have to worry about reloading all the changed files; the JSP engine picks them up automatically.
Because Java Server Pages eventually become servlets, it's difficult to point to any technical disadvantages of a JSP that aren't also present in servlets. The greatest disadvantage I've seen in practice is related to the greatest strength of JSP: the capability to mix in Java code with HTML. If you aren't careful in organizing your code, you can end up with an ugly mess: huge JSP files with HTML interspersed between huge blocks of Java code. Things only get worse if you do a lot of JavaScript in the page, too. It can be terribly confusing to look at a page and not know whether you are looking at server-side Java code or client-side JavaScript. Fortunately, you will learn ways around this in the next few chapters.
The Advantages and Disadvantages of Servlets
For the most part, the advantages of servlets are the disadvantages of JSP and vice versa. Because servlets are Java classes, you don't end up with a huge mess of Java, HTML, and JavaScript. Everything in your servlet is Java. Of course, when the servlet is generating HTML or XML, you might find that you still have a huge mess in the form of ugly out.print and out.println statements.
Servlets are not always automatically reloaded by the servlet engine, although that situation will hopefully change in the future. You also need to specify a special URL or at least a URL pattern (such as /servlet/) for executing a servlet, although for a JSP you only need to have a filename that ends with .jsp. This makes your site configuration a little more tedious to maintain.
It probably sounds like I'm biased in favor of JSP, and I can't really dispute that. Because a JSP eventually becomes a servlet, you have the entire servlet API available to you from within the JSP.
There is an interesting combination of servlets and JSP that has been used by many people around the world. When the initial request comes in, it is handled by a servlet. The servlet performs any business logic (fetching data from the database, doing computations, pulling data in from other sources). When it's time to send a response back to the browser, the servlet calls a JSP to render the output. This uses the strength of each of these technologies: The servlet is a simple Java class, whereas the JSP is a template geared towards generating output. You will learn more about this technique in Chapter 7, "Organizing Your Application."
If you take a little extra time, you can create a JSP that doesn't contain any Java code at all. It might seem a little strange to make a JSP with no Java code, but throughout the rest of this book you will learn about built-in JSP tags that let you access Java objects, and also a tag-extension mechanism that lets you create new JSP tags. Using these features, you can easily eliminate embedded Java code, which some would argue is the best way to use JSP.
It probably sounds a little too simplistic, but you should use the technology that best fits your requirements, or at least your comfort level. If you have a lot of static HTML, XML, WML, or other textual markup language, use a JSP. If you are sending back binary data, such as an image or an audio file, a servlet is probably a better bet (not from a technical standpoint, just an aesthetic one). If you aren't comfortable with your Java skills, start playing with JSP to get your feet wet.
Troubleshooting
Can't Compile the Servlet
Why won't my servlet compile? The compiler reports that it can't find the javax.servlet package.
Your classpath isn't set up correctly. You need to locate the servlet.jar file (it might have a different name) and add it to your classpath.
The Servlet Won't Run
Why does the Web server gives me a 404 (File Not Found) error or a 500 (Internal Server Error)?
This is usually either an installation problem or a classpath issue. One way to check the installation is to run one of the default servlets that comes with the servlet engine. Check Appendixes C-F to find out which default servlets your servlet engine comes with. If you can't run one of the defaults, you need to check the configuration of your servlet engine and possibly reinstall it. If you can run the default servlet, but not your own, your classpath probably doesn't point to your servlet. Also, if you change the classpath after you have started the servlet engine, you need to restart the servlet engine to pick up the changes.