Networking your Java Applets

Let's say you're ready to start networking your Java applets. As we discussed last week, there's realistically only one host that you're going to network with--your server.

What are you likely to be doing? Well, we wouldn't want to suggest any limits to your creativity. The scope of applet capabilities suggests that you might want to interact with the Web server that served your applet (and it's containing HTML page)--possibly pulling information from the server, or interacting with an existing CGI on the Web server (for those of you unfamiliar with CGI, Yahoo has a sizable section on the topic).

The URLConnection class we've been bringing up lately makes this very easy. More generally, you might dialogue with any other network service running on your server machine, be it e-mail (e.g., it would be relatively easy for a Java applet to communicate with a UNIX mail server for purposes of sending mail), FTP, Telnet, all the way through NFS (the Unix defacto standard system for sharing files over a network), as long as you have the patience to teach your applet how to speak to it.

Frequently enough your task will require something unique on your server: Take the Java chat clients, for instance, that have been all the rage lately. All require a server-side component that exchanges data between the clients, and many such pieces of server software have been written from scratch for the purpose. There's no reason to write this software in Java; yet, strangely enough, many people who start working with the Java networking interface do not want to go back to programming in C. Fortunately, you rarely have to. (We'll cover the Java server-side program in an upcoming column.)

For now, let's start at the basics. Possibly the simplest thing you can do, relatively speaking, is to simply load a Web page from your host Web server and display it, as in the following example:

---

---

This is the applet source. You may notice that it imports from four different packages, making it seem a fairly complex applet, but this is deceptive. It takes a little from each, as you'll see. We start by creating a URL object with the URL of the Web page we want to load. Since we've chosen to load the page you're viewing right now, we get the URL we want conveniently provided by the getDocumentBase() method in the Applet class.

Once we've created our URL object, we parlay it into a URLConnection object with an openConnection() method call. All this is encased in a try block, because this operation, being dependent on the vagaries of the network, may need to throw an exception (specifically, an IOException) in case something doesn't work.

You can see that once we do this, we call another connect() method on the URLConnection itself. Technically speaking, this method invokes the actual network connection to the server. Then we "attach" it to a data stream that we can read at our leisure, hence, the need to import java.io.*. And if you've been paying attention, you'll notice a pattern here: We get the stream we want by calling a method on the connection object. Specifically, getInputStream().

This method returns an "InputStream," and we use that to construct a "DataInputStream" (a special kind of InputStream), which gives us certain special abilities for reading information through it.

Our next step was to create the bit of interface used to show what we've actually loaded--a TextArea of moderate size. The next try block that you see is where the actual work happens. Here the role of the stream becomes obvious: This is how you can read and write data in the outside world. Streams are attachable to a number of different, highly interesting things. (Of course, we'll be talking about them here shortly; in the meantime, check out the Sun tutorial on them.)

The loop we created simply reads lines (which the DataInputStream has given us the capability to do) from the URLConnection and deposits them (appends them, technically) into the TextArea we've created. Then, once we add() the TextArea to the screen, the information we've transferred is visible. As a side note: Notice that we put a line in both of our catch blocks:

   catch (IOException ioe)
   {
       System.err.println(ioe.toString());
   }

This is good practice; in the event that an exception is thrown, it will be "displayed" in the Java console. You can see here one of the numerous small blessings of handling errors in this fashion; the exception, being an object, can happily represent itself however you want, from whichever data it carries around with it. You'll find that, sometimes to great effect, a significant number of Java objects return a meaningful sentence or two when their toString is called. In this case, the exception will describe itself to the user with no need for intervention.

Next week, there will be more telling examples. For now, think about the ramifications. We were just able to load and process data over the network with a few dozen lines of Java. It doesn't take any extra magic to start processing information obtained in this way. And this is just the beginning.

Past installments of Java Jolt