Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com

Dodge the traps hiding in the URLConnection class

The URLConnection class's generic design causes snags when posting to a URL

By Michael C. Daconta, JavaWorld.com, 03/23/01

  • Print
  • Feedback
.
A pitfall is Java code that compiles fine but leads to erroneous, and sometimes disastrous, results. Avoiding pitfalls can save you hours of frustration. In this article, I will present a pitfall you might encounter when posting to a URL, and another that plagues Java beginners.

Pitfall 5: The hidden complexity of posting to a URL

As the Simple Object Access Protocol (SOAP) and other XML remote procedure calls (RPCs) continue to grow in popularity, posting to a URL will become a more common and more important operation -- it is the method for sending the SOAP or RPC request to the respective server.

While implementing a standalone SOAP server, I stumbled upon multiple pitfalls associated with posting to a URL, starting with the nonintuitive design of the URL-related classes and ending with specific usability pitfalls in the URLConnection class.

A simple HttpClient class would be the most direct way to perform an HTTP post operation on a URL, but after scanning the java.net package, you'll come up empty. Some open source HTTP clients are available, but I have not tested them. (If you have tested those clients, drop me an email regarding their utility and stability.) Interestingly, there is an HttpClient in the sun.net.www.http package that is shipped with the JDK (and used by HttpURLConnection), but it is not part of the public API. Instead, the java.net URL classes were designed to be extremely generic and take advantage of dynamic class-loading of both protocols and content handlers. Before we jump into the specific problems with posting, let's examine the overall structure of the classes we will use (either directly or indirectly).

This UML diagram of the URL-related classes in the java.net package illustrates the classes' interrelatedness. (The diagram was created with ArgoUML -- see Resources for a link.) For brevity's sake, the diagram shows only key methods and no data members.

URL classes

Pitfall 5 centers on the main class: URLConnection. However, you cannot instantiate that class directly -- it is abstract. Instead, you will receive a reference to a specific subclass of URLConnection via the URL class.

Admittedly, the figure above is complex. The general sequence of events works like this: A static URL commonly specifies the location of some content and the protocol needed to access it. The first time the URL class is used, a URLStreamHandlerFactory singleton is created. That factory generates an URLStreamHandler that understands the access protocol specified in the URL. The URLStreamHandler instantiates the appropriate URLConnection class, which opens a connection to the URL and instantiates the appropriate ContentHandler to handle the content at the URL.

So what is the problem? Because of the classes' overly generic design, they lack a clear conceptual model. In his book, The Design of Everyday Things (Doubleday, 1990), Donald Norman states that one of the primary principles of good design is a sound conceptual model that allows us to "predict the effects of our actions." Some problems with the URL classes' conceptual model include:

  • Print
  • Feedback

Resources