Although G1 is available for use in this release, note that production use of G1 is only permitted where a Java support contract has been purchased. G1 is supported thru Sun's Java Platform Standard Edition for Business program.
The open-source community is (and always has been) a little paranoid about open source efforts by large companies. And just because you're paranoid doesn't mean they're not out to get you. This is natural because companies ultimately answer to their shareholders first and foremost and typically are only one CEO change away from using some combination of software patents, trade secrets, copyright, trademark enforcement, litigation and lobbying for legislation to enforce their intellectual property "rights".
Sun has always been a reluctant (and arguably fair-weather) supporter of open-source. The Java open source story really entered the limelight in the late 90s when there was a concerted effort to create an ISO standard for Java. Arguably at this time Microsoft was seeing to blunt or even fracture the Java behemoth that threatened to loosen users' lock-in to Windows. Ultimately Sun won this battle by winning the highly unusual position as official submitter for the Java ISO standard in 1997. I say "highly unusual" because it is typically industry bodies or standards organizations that submit ISO standards, not large companies.
Well, no standard was submitted and this effort was ultimately abandoned in 1999. Java open source efforts ultimately culminated with Sun's release of OpenJDK under the GPL with some minor exceptions relating to third-party code in the class library.
Does this signal Oracle's intent to create tiers of Java? This must surely be a big nail in the coffin for the "write once, run anywhere" mantra that initially propelled Java to prominence even though it at best had a lot of caveats and at worst was a myth and that's still the case. "Write once, test everywhere" is arguably more accurate.
This move threatens Java in three important ways:
- It undermines confidence Sun/Oracle's credibility to lead the platform forwards. Credibility is crucial;
- Customers--both current and potential--must now consider the very real risk of a fractured or tiered platform; and
- With OpenJDK available under the GPL, the risk of Java forking is very real. Sun's stewardship of MySQL has already resulted in that project being forked. Forking can be healthy but for a Java, which is a language and class library that has succeeded at least in part due to it's consistency and ubiquity--forking would, in this writer's opinion, be a disaster.
Remember, not even Microsoft differentiates .Net with commercial and non-commercial features. Sure, Mono notwithstanding, there is a tie-in to Windows but that's not the same thing.
One might reasonably argue "but it's only a garbage collector". To a degree, that's a fair observation. The danger is not in this one feature but rather what it signals to the Java community and what the Java community assumes it to mean, which are not necessarily the same thing. The risk of a self-fulfilling prophecy here is very real.
- Three months after the release of a major version of Spring, it will no longer have patch releases made available publicly
- All fixes will continue to be committed to the public source repository and
- paying customers will have access to later point-releases, but
- those releases will not be tagged publicly
Don't be fooled: those changes are significant. If your application was shipped with Spring 2.0.8 and you need to pass on a fix released and committed to the public repository, you no longer download the next release. Basically you will be responsible for packaging and tagging a particular Spring release in this instance.
Back to Java, it has already ceded the desktop to the Web (as part of a much larger trend) and .Net. Java now is all about the server and I guarantee you that something like garbage collection is of critical importance to many server-based applications. Supporting and testing against multiple garbage collectors (eg for caching) increases the cost and the risk to the vendor. How soon before particular products will require such features?
To all the Java developers out there: watch this issue very carefully. Be vocal in your opposition to the fracturing of Java.