The Monetization of Java Begins?

I was rather disturbed--and a little alarmed--today to read that Slashdot is reporting that the much-anticipated G1 garbage collector will not be free. The release notes for Java 6 Update 14 state:

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:

  1. It undermines confidence Sun/Oracle's credibility to lead the platform forwards. Credibility is crucial;
  2. Customers--both current and potential--must now consider the very real risk of a fractured or tiered platform; and
  3. 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.

Last year saw the advent of similar stirrings in SpringSource following the venture capital funding they received. They announced a significant change in distribution policy:

  • 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.

6 comments:

Anonymous said...

good observation!
I think your'e right about java-for-server-where-GC-is-crucial!

Anonymous said...

have we started to feel the wind of Oracle?
that's not a good sign for future..

Anonymous said...

I get what you're saying, I do. But surely what this is more like is IBM's JRocket JVM? Nobody is changing the language or its functionality, but what they're saying is "if you want to use the new high performane JVM then you have to pay" this isn't a new idea.

What would be worrying if they started pushing JVM specific functionality back in to the language in general, this would introduce the tiering you discuss.

Your Java code will run on the both types of JVM just with better performance on the G1 one.

Lets focus our attentions on other aspects of the acquistion, such as the continued commitment to OpenJDK and getting a specification for Java 7

Anonymous said...

I did not get the impression Sun wants to monetize on G1. It is rather about the current state of readiness. They rather say - do not dare to use it in production unless you have a support contract.

William Shields said...

By the way, InfoQ has now written about this:

http://www.infoq.com/news/2009/06/g1-paid

William Shields said...

This issue has now been clarified by Sun as a "misunderstanding": http://www.cforcoding.com/2009/06/update-on-g1-garbage-collector.html

Post a Comment