A Look at the URLConnection Class

Last week, we showed you the basics of making a URLConnection. This week, we're going to begin focusing on the details of such an exchange, and take in the relative merits of our example's approach compared to other ways the same task could be accomplished.

By using the built-in objects designed for Web-based networking, we've touched on a few of the issues involved. We're now working our way up to trying the same thing without the URL connection, so as to reveal more of the details of "regular" networking. This should also help to make clear exactly what using the URLConnection class does for us.

If you take a look at URLConnection, you'll find it's a very complex class with a plethora of methods implementing a fantastic number of features. This is relatively sensible; from a design perspective, this class is the keeper of a tremendous amount of information regarding the HTTP protocol. This is, now at least, a fairly complicated system of communication with a variety of features.

Not only that, but the design of this class hints at a very sophisticated way of thinking about the network, far more so, that is, than the way we used it the last time. If you recall, we used this connection to open a stream from the URL we chose, and then we read from the stream. But look at some of the methods within URLConnection--for example, getContentType(), getContentEncoding(), and getContentLength(). These methods return actual fields from an HTTP header--the standardized piece of text that's returned with every Web page served by any compliant Web server. This suggests that this information is incorporated into and kept in the URLConnection object for a purpose, and that's true.

We're talking here about the functionality tied up in the getContent() method. If you check it out, you'll notice it returns a generic Object, that is, it could return just about anything. The underlying idea is that it returns an object corresponding to whatever type of content is pointed to by the connection. To do so, it uses the information we discussed (which includes the mime-type of the content as given by the Web server in question) coupled with a "Content Handler" object to create an object of an appropriate type, and to load it with the information on the other end of the connection.

In real terms, had we called getContent() on the URLConnection in our previous example (once it was properly connected, of course), it should have created a kind of HTML object and filled it with this Web page. We might then call toString() or some similar method on this object to get the HTML source. Of course, that would be rather mundane; the power from working in this fashion comes from the other methods that one might implement in an HTML object, such as (hypothetically) drawInWindow() or toPostscript().

All this magic is accomplished with something called a ContentHandlerFactory; this is the class that uses the information in the URLConnection to build (hence, factory) the proper content object. There's actually a default content handler, although our impression is that it's not the same across every implementation of Java. Naturally, if you want to exploit this scheme yourself, you can create you own ContentHandlerFactory and tell your URLConnections to use it with the setContentHandlerFactory() method.

This way of thinking about the network and of handling information received over it is a good example of some of the more clever things that are being done with object-oriented design in recent years.

In concluding our look at the URLConnection class, it's also a good idea to note just a few other special methods it contains; specifically, there are a small number of "setup parameters" that are described in better detail following the list of methods on the URLConnection API listing.

By contrast, the Socket class is much, much simpler, and in exactly the ways you might expect. Although at its core it's the same as a URLConnection, by comparison it lacks the large number of states, parameters, and actual content-related methods that we've been talking about. It knows nothing of URLs, and instead works on host names or network addresses.

Coming up next week will be a demonstration.

Past installments of Java Jolt