Java Serialization and Sockets

I remember working with sockets years ago and thinking how much work was involved to get simple messages over the pipe. Even though I was doing the sockets programming in Java, and Java greatly simplifies the actual socket connections, it was still intimidating designing a communications library and breaking everything up into bit streams.

Since then I've tried a number of high level communications schemes like CORBA, RMI, and web services. Let's face it, CORBA was just painful. The price of getting that high level connection was just too high. RMI was big improvement. With surprisingly little effort you could send fully instantiated objects over the pipe .. as long as the pipe didn't include any firewalls. Web services work great with firewalls, but you have to jump through hoops to maintain state. In case you haven't noticed, state is a pretty useful thing to have. Working in a stateless environment seems to be a step back into the dark ages. Of course, I can implement my own session state, but wasn't the initial goal to make things easier?

Recently I've been working with sockets again. But this time I've thrown Java serialization into the mix. This allows me to serialize high level Java objects and send them over the pipe without writing all the usual code to break the object down into bits and then recreate it on the other end. Sure, you still have to develop a communication language for the sockets, but far fewer commands are required, as everything is essentially just treated as a single piece of data.

While using sockets may seem like a step backwards, it is the single solution that provides both inherent statefulness and simple firewall traversal. I certainly won't be advocating sockets for everything, but if you find yourself working too hard just to get your network layer functioning maybe you should consider it.

Java and dot Net Integration with IKVM

A coworker of mine recently discovered a great Java and dot Net integration tool at IKVM.net. It is a customized JVM written in dot Net that provides a mechanism for dot Net to access Java code. I was skeptical at first, but have since been quite impressed with how well it works. We have a need for just such a tool on one of our current projects. As an interim solution we need to allow a dot Net application to access our Java framework. The distributed Java code uses RMI to communicate between modules. We provide a lightweight 'connector' that hides the communication layer and exposes public methods for the dot Net client. In the future we may provide web service style access and forgo the IKVM approach. But having done dot Net -> Java web services in the past I am not excited about doing it again.

Java Plugins

I learned something pretty neat today. The team at my office is working on a medium-sized Java project and we have the need (desire really) to develop some components as plugins. One of the guys came across some example code to do just that (thanks to the folks at javaranch.com). After seeing the example we realized that Java has a handy utility built right in that handles plugins nicely. The ClassLoader class (sorry, I forgot the namespace and don't have a reference handy) makes quick work of plugins. And check out his friend UrlClassLoader to load code from any standard URL style resource. Stuff like this is why I like Java. I have developed plugins before in C++ and Linux. It was not this easy. So go ahead and make your code plugable. It's easy!

Why dot Net?

Someone asked me a while ago "what is dot net"? Typically I would just say "dot net is Microsoft's answer to Java", so I did. But it really got me thinking. Why did Microsoft go through all the time and effort to create this entirely new development framework? Well it probably got started with their custom Java JVM stuff back in the nineties. Sun said "you can't call that Java", so they called it c#. But why continue to pursue it? Sure, the MFC was old and ugly. But why not create a new native API? The big advantage of Java is its portability. It takes a performance hit to achieve that portability. So why would Microsoft opt for an interpretive environment but leave out the portability part? Maybe they didn't. There are a couple of possibilities here.

1) Microsoft intends to make an entirely new OS, like Apple did with OS X. And dot net is their compatability layer. When they deploy their new OS it will come with a dot net framework (as most OSes have Java frameworks now). This will ensure a large base of existing apps at launch time.

2) Microsoft intends to support other OSes. They could release dot net frameworks for Mac and Linux and add a whole new customer base.

Option 2 seems a lot less likely, since Microsoft has never liked playing nice with others. But I think option 1 has merit. I think Microsoft has found themselves in an unfamiliar position .. They are starting to see real competition. Apple is providing competition from a traditional business model and Linux is providing a very different kind of competition. I think it's Linux that Microsoft is scared of. Their typical model of sue-first doesn't work as well with open source software. Either way, I think Microsoft will actually have to innovate to maintain their dominant status. The Windows platform is hopelessly broken. And Microsoft's insistance on maintaining legacy compatibility has played a large part in that. I am anxious to see what someone with that much money and smarts can do when they turn their attention towards coding instead of litigation.

Database in a File

For the past few years I have been using the SQLite database on a variety of software projects. The more I use it the more uses I find for it. Perhaps the best use I have found is in creating binary file formats with my applications. SQLite gives me the benefits of using a binary file format (speed, size, a bit of opaqueness) without the fuss of creating and (more importantly) maintaining custom code. And since SQLite works as an embedded database there is nothing to setup in advance. This is a huge benefit! Recently I have started using the Java connector for SQLite. I write a lot of code in Java, so I was happy to see SQLite get a first class connector. They even include a pure Java version, so you can take advantage of SQLite files without having to deal with platform specific issues. For improved speed you can opt for the native version. It uses the JNI interface to perform all the file IO in C. The trade-off is you have to build and install the native C library for your target system.