Tuesday Mar 03, 2009

Closing a URLClassLoader

Complex Java programs such as application servers sometimes create their own class loaders using the URLClassLoader type. With URLClassLoader, applications can load classes and resources from a search path of URLs, and the following URL types are supported:
  • file:
  • jar:
  • http:
which load from file-system directories, jar files, and http servers respectively.

A frequent problem has been how to support updated implementations of the classes and resources loaded from a particular codebase, and in particular from jar files. In principle, once the application clears all references to a loader object, the garbage collector and finalization mechanisms will eventually ensure that all resources (such as the JarFile objects) are released and closed. The application can then replace the jar file, and create a new URLClassLoader instance to load from the same location, but this time using the new implementation of the classes/resources. However, since it can't be predicted exactly when finalization and garbage collection will occur, this causes problems for applications which need to be able to do this in a predictable and timely fashion. It is a particular problem on Windows, because open files cannot be deleted or replaced.

To alleviate this problem, URLClassLoader has acquired a new method called close() (since b48 of jdk7) which effectively invalidates the loader, so that no new classes can be loaded from it. It also closes any jar files that were opened by the loader. This allows the application to delete/replace these files and if necessary create new loaders using new implementations.

The new method follows the familiar "Closeable" pattern, and URLClassLoader now implements that interface. The definition of URLClassLoader.close() can be seen here.

Monday Dec 11, 2006

HTTP server API in Sun's Java SE 6

Sun's implementation of Java SE 6 includes a light-weight HTTP server API and implementation. This is used internally by other components of Java SE, but it can just as easily be used for user applications to deploy simple HTTP server applications. The relevant API packages are: The first of these contains the API itself, and the second contains an SPI (Service Provider Interface) which allows alternative implementations to be plugged in. You are more likely to be interested in the first package.

You are probably wondering already about the package names, and why they are com.sun.httpserver rather than something like java.net.httpserver. What this distinction means, is that the API and implementation are a fully supported, publicly accessible component of Sun's implementation of Java SE 6. It does mean however, that the packages are not formally part of the Java SE platform, and are therefore not guaranteed to be available on all other (non Sun) implementations of Java SE 6.

So, what can you do with the HTTP server ?

First, the package allows programmers to create simple embedded http and https applications. The API is similar in some respects to the servlet API in Java EE, but this API is more light-weight and does not provide the facilities/services that the servlet container environment provides.

It does have some innovations like a pluggable thread model. What this means is that the server does not create threads for handling incoming Http requests. Instead, the management of threads is delegated to an Executor object provided by the application. A number of off the shelf Executor implementations are provided in Java SE 6, and the programmer can choose one (or roll your own).

The following table shows the main classes and interfaces that a programmer needs to know about for programming a HTTP server.

Class/interfaceWhat does it do?
HttpServer Listens on a particular port number and address for incoming Http requests
HttpsServer Same as for HttpServer except for Https requests
HttpHandler Programmer implements this. Handler is called to handle each incoming Http request
HttpExchange Encapsulates all of the information about a Http request and the corresponding response
HttpContext Represents one Http application on a HttpServer instance. It is identified by the URI path to the application, and has a HttpHandler associated

There are a number of other auxiliary classes in addition to the ones mentioned above. They provide services like basic http authentication and a filtering mechanism, that can be applied to all incoming requests.

So that is a very brief overview of the Http server API. I plan to augment this with some code samples of how to use the API, how to configure the use of SSL etc.


Hi. I am Michael Mc Mahon, an engineer at Sun Microsystems. I am using the occasion of the launch of Java SE 6 to set up my own blog. I work in the Java Security, Networking and Libraries group at Sun, and plan to write occasionally about some cool stuff we are working on. My next entry (to follow shortly) will be about the new Http server API and implementation in Java SE 6.



Top Tags
« April 2014