The aim of the project is to produce a large and healthy community of those interested in runtime platforms tasked with:
Create a compatible, independent implementation of J2SE 5 under the Apache License v2 Create a community-developed modular runtime (VM and class library) architecture to allow independent implementations to share runtime components, and allow independent innovation in runtime components
In other words, this is providing both a Java Virtual Machine and also a suite of J2SE 5 libraries under an Apache Public License. This is way cool. The only competitor in the open-source space are licensed under GPL, which restricts their use in some businesses. However, both the EPL and APL tend to be accepted more readily for bundling with applications, since there’s less of a viral nature to them.
The project is being very carefully played out, by avoiding contamination of any IP from competitor source implementations. Anyone who’s had access to any other source VM isn’t allowed to contribute to avoid the possibility of code contamination. However, the class libraries are partitioned into different units so it makes it possible for such a person to contribute to (say) AWT classes if before they’d only worked on IO.
The VM has a base set of 23 classes which are semi-internal to the VM (things like Object, Class, String, Thread etc.). Then there’s an interface to the VM process itself, and this allows a bootstrap VM to be very small, and instead pull in (from one or more implementors) the remainder of the VM. The goal is that it’s possible to swap out separate implementators of the VM, perhaps for using different types of devices.
Modularity is key and the Java libraries has been split into multiple packages (like IO, Net, AWT, Util etc.). Unlike the Sun VM, the packages are split into multiple Jars. The Jars themselves use OSGi manifests, and in fact, the 23 classes are used to bootstrap a mini OSGi bundle loader which then loads the bundles in the VM implementation. Not only that, it means that you’ll be able to bundle a sub-set of the JRE by avoiding some unnecessary libraries (e.g. AWT) in your application, and you’ll only be using open-source code. If I were Sun, I’d be really worried about it; it’s basically the last bastion of their model. We now have a VM and the minimal amount of code to get off the ground and then use your own bundles.
But this is an OSGi VM. It may even supercede Equinox or Felix. If there’s an OSGi into the VM, you’ll be able to have two applications running that are dependent on different versions of a VM. (Actually; different versions of a VM’s libraries, to be specific.) But the coolness doesn’t stop there; you’ll be able to ship security updates to the core VM as OSGi bundle updates. If there’s a security patch for (say) the net libraries, you won’t have to wait for your VM to be updated; you can just update the net bundle.
This might sound like an empty pipe dream, or a set of empty promises. But they’ve not only got a VM that’s capable of building, it’s also capable of running a few Java programs. The first demo was RSSOwl, which is Ben’s news reader on the Eclipse platform, and launched it in Harmony. Seamless. Not only that, but it’s also capable of hosting the full Eclipse JDT platform, as well as using the Eclipse JDT compiler to be able to build and run Java applications inside the Eclipse workbench. And this is in 10 months since the project started.
Of course, it’s not complete yet (or you’d have heard about it). There’s AWT missing for a start (though SWT is pretty much out-of-the-box, since it’s handled by the OS). It’s not possible to run everything; there’s code coverage statistics to find out how classes are implemented/used by other systems. But it’s getting there, and in the next couple of years, this will be the de facto standard VM used by everyone. You’ll be able to bundle it with your RCP applications, and the OSGi bundles will be transparently handled by the VM. This is going to be an interesting few years.