Home > Articles

Getting Started

  • Print
  • + Share This
This chapter is from the book

A Brief History of JSP

To understand JSP, you have to understand where JSP came from. The Web started with HTML, and JSP's history starts there, too, so the first step is to take a look at HTML.

HTML

The pages into which we embed our JSP are Hypertext Markup Language (HTML) pages. (This book assumes you are already familiar with HTML.) HTML is a specification of the World Wide Web Consortium (W3C), and you can find the official home page for HTML at http://www.w3.org/MarkUp. The current version of HTML is 4.01, and you can find HTML's official specification at http://www.w3.org/TR/html4/.

TIP

If you want to brush up on HTML, there are many resources on the Internet. Here's a good one that lists all HTML tags and attributes by browser version and what they do: http://www.willcam.com/cmat/html/tags.html.

We've already seen our first HTML example, ch01_01.html; that example didn't do anything except support a title for the page and display the text Hello there!:

<HTML>
  <HEAD>
    <TITLE>
      A Web Page
    </TITLE>
  </HEAD>

  <BODY>
    Hello there!
  </BODY>
</HTML>

That's okay as far as it goes, but it doesn't go very far. This page is very static, and Web developers wanted more as the Web became more and more popular. At first, client-side programming became popular, using script languages like JavaScript.

JavaScript

Despite the name, JavaScript is not related to Java. It actually began in 1995, when a Netscape Communications Corporation developer named Brendan Eich was given a new project to work on. The original idea was to give Netscape Navigator something extra; Eich took a look around and decided that what was needed was a scripting language that was fast and easy to use.

He called his creation LiveScript, but it was renamed JavaScript (although developed by Netscape, Sun had the trademarks on Java, so, interestingly, the name JavaScript is actually a trademark of Sun Microsystems). The new language was announced in a joint press conference with Netscape and Sun on December 4, 1995.

Unlike JSP, which is all about programming on the server, scripting languages like JavaScript are all about programming on the client side, in the browser. You enclose your JavaScript code in a <SCRIPT> element in an HTML page—for example, you can see how to use JavaScript to write the message Hello there! to a Web page while that page is being loaded in Listing 1.2.

Listing 1.2 Using JavaScript (ch01_02.html)

<HTML>
  <HEAD>
    <TITLE>
      A Web Page
    </TITLE>
  </HEAD>

  <BODY>
    <SCRIPT LANGUAGE="JavaScript">
      <!—
        document.write("Hello there!")
      //—>
    </SCRIPT>
  </BODY>
</HTML>

This creates the same results as we saw for our HTML page in Figure 1.7, but now we're using JavaScript to write to the Web page. Client-side programming like this can be useful—you'll see that we can use JavaScript to pass data to JSP documents on the server—but it's extremely limited. As a result of security restrictions, for example, you can't access files from JavaScript. And because JavaScript has to be built into the browser, it has to be relatively small, and can't contain more than a small fraction of the power of a full programming language like Java. In fact, during all the time HTML and scripting languages like JavaScript were developing, so was Java.

Java

Java wasn't originally created for the Internet. The first version was actually begun in 1991 and written in 18 months at Sun Microsystems. In fact, it wasn't even called Java in those days; it was called Oak, and it was used internally at Sun.

The original idea for Oak was to create an operating system-independent language. Many programmers were confining themselves to programming for the IBM PC at that time, but the corporate environment can include all kinds of programming platforms, from the PC to huge mainframes, and the inspiration behind Oak was to create something that could be used on all those computers. (Actually, the original inspiration for Oak was not what you'd call especially glamorous—Sun wanted to create a language it could use in consumer electronics. )

Oak was renamed Java in 1995 when it was released for public consumption, and as you probably know, it's become very popular. Even though it's not targeted at the Internet, you can still use it to display the message Hello there!; Listing 1.3 details a small Java application named ch01_03.java that does just that.

Listing 1.3 A Java Application (ch01_03.java)

public class ch01_03
{
  public static void main(String[] args)
  {
    System.out.println("Hello there!");
  }
}

To run this example, you must compile ch01_03.java and create a Java .class file: ch01_03.class. The compilation process creates this .class file, which is what you need to run the program.

You compile ch01_03.java with the Java compiler, which is named javac. If you've set up your path to include the Java bin directory as we saw earlier, you can use the javac command at the command prompt; here's how that might look in Windows (make sure you're in the same directory as ch01_03.java):

C:\>javac ch01_03.java

This creates ch01_03.class, which you can run with the Java tool, simply named java. Here's how that would look in Windows:

C:\>java ch01_03

You can see the results in Figure 1.8, where our Java application is displaying the message Hello there!

Figure 1.8 Running a Java application.

JSP is based on Java, and a lot of this book is about learning to use Java. Java's a big part of the Internet now because Sun couldn't ignore the Internet, and Java's first attempt at working with the Internet was to introduce applets.

Java Applets

An applet is just a Java .class file that's specially written to display graphics in a Web browser; you embed applets in Web pages using the HTML <APPLET> element. When run in a Web page, Java applets are downloaded automatically and run by the browser, displaying themselves in the space you've allocated for them in the page. They can do anything from working with graphics and displaying animation to handling HTML text fields and buttons.

Here's an example called ch01_04.java. The Java applet you see in Listing 1.4 displays our Hello there! message.

Listing 1.4 A Java Applet (ch01_04.java)

import java.applet.Applet;
import java.awt.*;

public class ch01_04 extends Applet
{
  public void paint(Graphics g)
  {
    g.drawString("Hello there!", 60, 100);
  }
}

To use this applet, you must first compile it with javac:

C:\>javac ch01_04.java

This creates ch01_04.class, which you can use in the HTML <APPLET> element. Here's a sample Web page that does this by setting aside an area 200x200 pixels in which to display the applet in Listing 1.5.

Listing 1.5 Displaying an Applet (ch01_05.html)

<HTML>
  <HEAD>
    <TITLE>A Web Page</TITLE>
  </HEAD>

  <BODY>
    <APPLET CODE="ch01_04.class" WIDTH="200" HEIGHT="200"></APPLET>
  </BODY>
</HTML>

If you store the applet, ch01_04.class, and this Web page, ch01_05.html, in the webapps\ch01 directory, you can see the applet at work by navigating to http://localhost:8080/ch01/ch01_05.html, as you see in Figure 1.9.

Figure 1.9 Viewing an applet.

Applets can display text like this, along with buttons, and so on, but like JavaScript, they're very limited. In fact, their time is mostly past as new client-side applications like Flash take over; the standard version of the newest Netscape Navigator no longer even supports applets by default.

But the Internet was still there to conquer. With the demise of applets, Java turned to the server side of things, and its first step in the server was to implement servlets.

Java Servlets

Java servlets were the first real attempt to get access to the full power of Java in Web applications. Like applets, servlets are written completely in Java; you compile them into .class files, and—using servers like Tomcat that can support servlets—you can navigate directly to those .class files and view the results in a browser. In this way, a servlet can almost be thought of as an applet that runs on the server side (as the name servlet is meant to imply).

Listing 1.6 shows a sample servlet, ch01_06.java, written in pure Java that will display our message.

Listing 1.6 A Java Servlet (ch01_06.java)

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class ch01_06 extends HttpServlet
{
  public void doGet(HttpServletRequest request,
    HttpServletResponse response)
    throws IOException, ServletException
  {
    response.setContentType("text/html");
    PrintWriter out = response.getWriter();

    out.println("<HTML>");
    out.println("<HEAD>");
    out.println("<TITLE>");
    out.println("A Web Page");
    out.println("</TITLE>");
    out.println("</HEAD>");
    out.println("Hello there!");
    out.println("</BODY>");
    out.println("</HTML>");
  }
}

Compiling ch01_06.java into ch01_06.class takes an additional step we haven't seen before. Much of the support for servlets is not built into the core of Java, but is stored in a Java Archive (JAR) file named servlet.jar, which stores many specialized .class files internally.

Tomcat comes with servlet.jar (located in the jakarta-tomcat-4.0.3\common\lib directory), and to access it, we have to set the CLASSPATH environment variable, which is specific to Java. As you might expect from the name, CLASSPATH indicates where Java can look for the .class files it needs when getting an application ready to run; we're using CLASSPATH because we need a number of servlet .class files stored in servlet.jar. Here's how you can set the CLASSPATH variable to include servlet.jar in Windows (change the path to servlet.jar as needed):

C:\>SET CLASSPATH=C:\tomcat\jakarta-tomcat-4.0.3\common\lib\servlet.jar

Now Java can find what it needs to compile servlets. You might have already set CLASSPATH to other locations, so if you just want to add servlet.jar to the CLASSPATH without affecting the rest of what's already in CLASSPATH, you can do the following in Windows (like other environment variables, you separate the locations and JAR filenames in the CLASSPATH variable with semicolons):

C:>set classpath=%CLASSPATH%;d:\tomcat\jakarta-tomcat-4.0.3\common\lib\servlet.jar

You'll see more on using and setting CLASSPATH in Day 11, "Creating More Powerful JavaBeans." Now that we have access to servlet.jar, navigate to the directory where our sample servlet ch01_06.java is located, and use javac to create ch01_06.class (this assumes javac is in your computer's path) :

C:\>javac ch01_06.java

Now transfer ch01_06.class to jakarta-tomcat-4.0.3\webapps\ch01\classes—note that we have to use the classes directory for Java classes like ch01_06.class.

And that's it—all we have to do now is navigate to http://localhost:8080/ch01/servlet/ch01_06. You can see the results in Figure 1.10—note that it looks just like our original HTML document, but this time, we've created this Web page on the server.

Figure 1.10 Using a servlet.

TIP

The servlet in http://localhost:8080/ch01/servlet/ch01_06 tells Tomcat that you're navigating to a servlet that it should run. We'll see how we can make some configuration changes that will allow us to omit that term in Day 13, "Creating More Powerful Servlets," making this URL simply http://localhost:8080/ch01/ch01_06.

Servlets are very powerful, but they're not easy to program. As a result, they haven't become very popular. But Java and the Internet was a match meant to be—and the next step is JSP.

JSP

JSP is built on top of servlets, but JSP is much easier to program, and that's the whole point—that's why JSP has taken off.

JSP, a specification of Sun Microsystems, first appeared in 1998. The official versions, 1.0 and 1.1, both appeared in 1999, and both were very popular. The current version, 1.2, appeared in 2001, and is the most popular implementation yet; this is the version we'll be using in this book.

Internally, each JSP page is actually converted into a servlet by the server (we'll see exactly how that works in Day 13). In other words, this is really a book about servlets—but they're acting entirely behind the scenes.

NOTE

We'll also see how to create servlets in this book for some added power—see Days 13 and 14.

From our point of view, JSP pages are simply HTML pages with embedded Java in them. And by using JSP, we avoid all the hassle of creating full-blown Java applications—the server will do all that for us, taking our Java snippets of code and compiling them for us automatically.

It's clear that Sun had gotten the message about making things easy for the programmer when it came up with JSP, and we're the winners. Let's use JSP now to create the Web page we've already developed—you can see what it looks like in Listing 1.7, ch01_07.jsp (giving this document the extension .jsp means Tomcat will know that it is a JSP document and treat it accordingly):

Listing 1.7 A JSP Page (ch01_07.jsp)

<HTML>
 <HEAD>
  <TITLE>A Web Page</TITLE>
 </HEAD>

 <BODY>
  <% out.println("Hello there!"); %>
 </BODY>
</HTML>

Notice how simple this is—it's just a simple HTML page, with the extra element <% out.println("Hello there!"); %>. This element is called a scriptlet in JSP, and it encloses the Java we use to write the message Hello there! to the Web page. You can see the result by navigating to http://localhost:8080/ch01/ch01_07.jsp, as you see in Figure 1.11.

Figure 1.11 Our first JSP.

TIP

As you probably know, a Web server will send the document named index.html to the browser if that document is present in the directory you navigate to on the server, and you don't specify any other document. Similarly, index.jsp is the default for JSP documents—Tomcat will send that to the browser if you don't specify any specific document otherwise. If both index.jsp and index.html are present, the server chooses index.html as the default.

And that's it—now we've created and run our first JSP! Let's see what makes it tick.

  • + Share This
  • 🔖 Save To Your Account