Hot Swapping In Java

When one thinks of Java they might think of monolithic systems with components that are compiled together and linked against each other. A typical class might import some element from other packages (include packages in jars) but all of those files, packages, and jars, are known at compilation time. This is largely true, however, it is not set in stone. The Java Classloader is the magic responsible for pulling .class files into the current virtual machine's environment for use. By overriding the Classloader it is possible to change the available .class files at run time.

Overriding the Classloader is non-trivial, but fear not because there are open source libraries to accomplish this hotness for us. The one I will be using today can be found here. I'll present the code first and then we will go over a few points.

The interface Message and its two implementers are simple enough. It allows use to call a single method on each instance we load dynamically.

The main method will sit in a loop and wait for stdin input. When the main method is first invoked it takes the base path containing .java and .class files. This base path can even be dynamically changed with the library we are using, but I will avoid that for now. The main method will take input, inspect it, and call the corresponding method in Example.

Example is where we use the library to hot swap our Message Implementation. We hold one Class object named impl. Java Class objects hold information on a compiled class and allow us to make new instances of that compiled class. The Class object can hold any type of compiled Java class which is useful for the type of reflection we are going to do. The method changeImpl will look around from the basepath to try and find a match and will then change impl to hold the Class data for what it has found. The method speak uses the Class object to make a new instance and call the method Speak which the class has by implementing Message.

When we run this application we can change between HelloWorld and HelloHotswap and call speak accordingly. The code provided has no knowledge of HelloWorld and HelloHotswap, yet it can make use of it! In fact, if we wrote another Message implementation, compiled it and put it in the basepath's directory then we could load our new implementation without restarting the application. When we must have zero downtime this is a very powerful tool in the java tool belt.

Many open source libraries for dynamic loading exist and they can be useful for situations where we want to add functionality without shutting down our application. The ClassLoader and its underlying connection to the virtual machine allow these libraries to exist. By over riding the ClassLoader we can control the virtual machine's access to .class files. With this type of control we open the door to hot swapping at run time, which useful and a great dynamic-oriented addition to Java.

Writing a Java HTTP Server from scratch

During my second week at 8th Light I was asked to create an HTTP Server to serve TTT games to remote players. That being said, it really had nothing to do with playing TTT, which is a good thing, since the code was architecturally sound enough to place the game logic in a Package named TTTGame and create an independent package named TTTServer. The two packages only cross paths on one occasion, in an abstract class to integrate game logic and web requests.

About five minutes into development I stumbled upon the holy grail, the Sun class com.sun.httpserver. I could bind paths and verbs in different combinations to different handler classes (similar to Rails). Of course, my joy was killed and I was told not to use this class. I had to go forward and build the server from the bottom up.

I started with the essentials (this is Agile after all, I need to build iteratively out from the core). I had experience with Socket programming, although it was a little hazy. So I setup a Server class to wrap around a Server Socket and dish out new Client Sockets as they come in. This was easy enough. From here, I started to run into problems. My experience with Socket programming was to leave a connection open, send data, and close the Socket. Well, this doesn't work for HTTP. I had some learning to do. Namely, I need to learn about HTTP packets and a little refresher on rendering HTML.

The majority of this week was then spent building a Packet class and a Packet Parser class. Initially, I was attempting to build the Packet Parser in a laborious line-by-line fashion. This had to go, it was too painful to write and too ugly to use. Paul put me on the right path, at this point, by implementing the parser recursively. Not only did the LOC drop dramatically, but the class experienced a speed up (which is important with the potential for huge amounts of HTTP packets flying to and from in short amounts of time). I created a utility program to chart the two styles of parsing side by side.


I then wrote my Packet class to nicely integrate with the Parser and voila (as the French say) I had the groundwork of an HTTP Server. Now, I need to add routes based on path (throwing 404 errors when a path isn't valid), and integrating the game logic so a remote user can play.

Finally, the last item on my list of things to do is generate a Session Key for each user on my end and have the user then pass the key in to play their unique game (since we can not keep the Socket connection open throughout the entirety of the game).

Hopefully, I will have a hand made HTTP Java Server up and running in the near future.