When the Hudson/Jenkins split occurred in February, many Jenkins supporters pointed to Oracle as having some deeply evil and self-interested goal behind its sudden assertion that the project needed to become more stable and couldn’t move to GitHub. At the time, it certainly appeared this way, and Oracle took a beating from the open-source community for what was perceived as its attempt to usurp the project and try to make it into some sort of product it could sell.
Turns out, this wasn’t really the case at all: Oracle really was concerned with Hudson’s lack of stability over time. And it turns out that a lot of other developers were worried about the same thing. After all the noise and conflict, both Hudson and Jenkins are, essentially, moving in exactly the same direction: long-term support releases will be hosted on GitHub, and every quarter should see a new stable release of each project.
So what’s the only real difference between the two anymore? Well, now Hudson is under a real open-source foundation’s umbrella, and Jenkins remains on its own. While Jenkins will become more stable and see more attention paid to release versions, at the end of the day, it’s going to remain a project led by one man, while Hudson will now be a committee-driven enterprise-level software project. And there’s plenty of room for each approach in this big world of Java continuous integrations.
TCK kerfuffle aside, Oracle has remained committed to the OpenJDK. And with the news that OpenJDK will be the official reference implementation of the Java SE 7 specification, the company solidified its commitment to open-source Java. It could very easily have built its own Java internally and sold it in a manner similar to what Sun did. But instead, Oracle is keeping the primary version of the language’s environment open source and under the GPL.
Now, it should be noted that the TCK it’s offering to the OpenJDK is not being offered to the Apache Foundation. There is still a great deal of animosity between Oracle and the Harmony project. Harmony is a full implementation of Java SE 5 and some of Java SE 6, but neither forms of the project have ever passed a TCK due to the field-of-use restrictions involved therein. The TCK license still limits the range of devices onto which an approved Java can be deployed, and mobile devices are somewhat disallowed by the license.
Of course, it should also be noted that Oracle was one of the first members of the JCP to object to the TCK license terms. Unfortunately, it hasn’t fixed them. Yet.
It’s been a while since Oracle moved out new software from the OpenJDK. Of course, JRockit isn’t new software, but it’s new to Sun. Or, the former Sun. Instead of just pulling in neat features from the HotSpot JVM, Oracle has merged the features of JRockit and HotSpot, bringing the OpenJDK a best-of-breed JVM.
To that end, last month, Oracle open-sourced JRockit under the Binary Code License, an odd little open-source license used by Sun. Oracle has modified the license a bit, but provided it’s used for developing and not deploying, it makes JRockit free software. Developers will still have to pay for a license if they want to commercially deploy the software, but it’s nice to know they now have access to multiple JVMs without having to sign up for a service contract or a developer program to gain access to alternatives.