Etienne Gagnon has released version 1.11.1 of SableVM, a Java bytecode interpreter (that is, a virtual machine) written in C. "SableVM requires an ANSI/ISO C compiler (but preferably GCC) and a POSIX platform. It requires a strong memory model (sequential consistency) on multiprocessor systems." SableVM is available for GNU/Linux, Solaris, and FreeBSD. Version 1.11.1 is basically a bug fix release. SableVM is published under the GNU Lesser General Public License (LGPL). The developers claim it's written in portable C, but in my experience it's unlikely to be able to be built on anything except the latest and greatest Linux and possibly BSD. It will not build on Mac OS X or older versions of Linux:
checking for poptGetContext in -lpopt... no ***ERROR: libpopt is missing
:-(
On the one hand code reuse is good, and you don't want to reinvent the wheel. On the other hand dependencies are bad. Depending on libraries that are not likely to be available, or not likely to be available in the right version, severely hinders an application. (By the way, the SableVM developers list noticed my last post about this, and I got a lot of offers to help me build it, though most of them implied that it was Apple's fault that the libraries they needed weren't installed on the Mac by default. I don't think anyone noticed that I had also tried to install SableVM on Linux and failed there too due to unresolved library dependencies.) Ideally you want an application to require no external libraries, and to run on as old a version of the operating system as well. In XOM, I'm currently going to some effort to remove dependence on all external libraries so it will be possible to run it out of the box in Java 1.4 and later with only a single JAR file. It's not easy to do, and I may not succeed, but it's worth trying.
One interesting product that does this right is Cenqua's Clover code coverage tool. That tool depends on a lot of third party jars. However, rather than just bundling the JARs and requiring CLASSPATHs to be set up to include them all, they repackaged the JARs into their domain, and included them in the main clover.jar file. This means they don't need to be separately added to the CLASSPATH. It also means the versions they bundle don't conflict with other versions I may be using elsewhere. It's a nice touch, and one that makes the product quite a bit easier to use. Sun has also learned this lesson. In Java 1.5, the JRE includes the Apache Project's Xerces and Xalan. However, they've repackaged these classes into the com.sun hierarchy so these don't conflict with any later versions one may have installed elsewhere.
Dynamic libraries may have made sense ten years ago when computers with 8 megs of RAM and 40 megabyte hard disks were still common. In 2005, I think their time may be coming to an end. Dynamic libraries cause more problems than they solve. It's time to seriously rethink whether this is something we want to force on our users.