Wednesday May 24, 2006 links for 2006-05-25
-
Dynamic language + framework + JVM = heaven. Yep, it's Groovy on Rails.
-
OpenSolaris distribution now offers Java SE support.
-
Enquire Within Upon Anything.
Posted by webmink
( May 24 2006, 06:17:47 PM PDT )
Permalink
Comments [1]
No Unfair Advantage
One of the strong notes at JavaOne last week was hearing Jonathan Schwartz and Rich Green underlining that compatibility is key to open sourcing Sun's implementation of Java SE. That's the code from which the reference implementation is derived, and which is the source of most commercial Java implementations. While some are pretty uncharitable about compatibility, others like Ian Murdock join me in regarding it as the single most important aspect of the Java platform - Peter Galli reports my views. Understanding why I think this requires some explanation.
There are two dimensions to compatibility. The one everyone with developer genes can grok is about having the same APIs doing the same thing everywhere the word "Java" is used to describe a virtual machine environment. It's obvious this is a primary benefit of the Java platform and I would expect everyone to protect this dimension of compatibility, enforced or not. The market will self-select and reject any attempt at a Java SE implementation that doesn't work right. This aspect of compatibility needed heavyweight protection back in the 90s but these days is probably protected by market forces and will likely be enhanced, not diminished, by a switch to a F/OSS license (as well as by projects like Apache Harmony).
The other is more subtle. It's about ensuring no major vendor - Sun included - gets an unfair advantage in the market because they have been able to exert control in a way that yields a competitive benefit. While we are criticized for controlling java we also hear people ask 'How come you guys don't make money off Java? You control it'. That's the whole point! This sort of compatibility is not protected by market forces - indeed, market power is the chief vehicle by which the damage is done.
Imagine if there had been no JCP control over the Java platform when the WS-* wars started. We would have seen each of the powerful vendors involved modifying the Java implementations they distributed to reflect their view of web services - while remaining "compatible", of course. We would have seen those modified versions distributed with volume products like application servers and developer tools. They would have been everywhere, creating a playing field that wasn't level for everyone to compete. Preventing this took control, and was to everyone's benefit. That's why it's wrong to treat all control as damage. In this case, control prevented damage, which is presumably why those who were thwarted were and are critical to the point of being grudging even about praising what's obviously good.
It's also wrong to assert that open source is a panacea in preventing unfair advantage. James got very close to this concept when he mentioned hands-off control. That's one of the consequences of focussing on licensing instead of governance in an open source community, and it's exactly what I'm keen to avoid in the future of Java SE. I do believe it's possible to build governance where the participants are prevented from exerting undue self-serving control - Apache is probably closest to an ideal arrangement in that regard - but it's also possible to create structures that make sock puppets look independent.
It's interesting to see who is whining loudest right now and who is being helpful and thoughtful. The corporations with the most to gain from being able to subtly influence and direct the Java platform to their benefit through "hands-off control" have their staff dissing Sun as loudly as they can, even as the Java platform heads towards open source. Their attitude confirms for me that compatibility - in the sense of preventing anyone getting an unfair advantage - must remain the number one priority for an open source Java platform.
Posted by webmink
( May 24 2006, 05:38:39 AM PDT )
Permalink
Comments [5]
