Here's what's missing from the Gosling interview

Sun really wants to sell to the operators, and wants the developers to help them to do this.
Written by Dana Gardner, Contributor

Interesting interview on News.com with James Gosling of Sun Microsystems, mostly for what is not discussed. The tack that Gosling takes with Java leaves out three essential ingredients that the intrepid interviewer, Martin LaMonica, keeps trying to point to, but Gosling dodges.

1) Java has to be examined within the context of politics and power, not just technological capabilities and past market trends. Sun really wants to sell to the operators, and wants the developers to help them to do this. The politics is that Sun has alienated many of the largest Java community players. They have done this by insisting that Java is a tax, not an open standard. Sun has opined about how the economics of software has shifted to free and has waxed on about how the bazaar is where it's at, except for Java intellectual property. If Java were truly made open source three years ago, things would be very different.

The result is that the major Java ISVs and infrastructure vendors now view Java as a necessary legacy that they need to support, but are looking elsewhere to fund and expand innovation. Java is relegated to middleware plumbing, and as a partial solution to integration concerns.

Many large vendors, IBM as the exemplary example, essentially funded Java R&D so that Sun could later charge them to use it. They are not funding it anymore, and Sun does not have the wherewithal to lead on Java's future alone. The split over Java Business Integration (JBI) specification (JSR 208) is the future of Java politics, and it is not the direction of industry standards.

2) There is a gulf between what systems operators want and what developers do. Operators and developers work essentially in different but parallel universes. Datacenter and service delivery platform operators are motivated by much different forces of economics and productivity than are developers.

This gulf needs to be better bridged, yes, of course, and the incentives and vision of both groups need to be better aligned. This is a major cultural challenge for how well SOA actually pays off -- can app dev thinkers and deployment-minded thinkers be made to work in harmony across the software lifecycle?

However, Sun with Java has lost allegiance and panache with Western developers (regardless of what Gosling professes about China and India, which will follow suit with North America and Europe soon enough). Developers focus on the higher tiers of an n-tier architecture. The operators and the infrastructure architects focus on the big bucks platform purchasing decisions and strategic infrastructure direction calls. Both are still viewed as cost centers by CEOs and CFOs, but operators bear the brunt of cost-reduction edicts from on high.

Sun really wants to sell to the operators, and wants the developers to help them to do this. Architects are the key to it all: They know that Java is a link between the universes of development and deployment, but Java is currently being outshined in terms of the productivity-boost/cost-reduction appeal across all the groups: developers, architects, and operators.

Developers will continue to want to develop their way -- merrily scripting away within open-source frameworks -- to make their deadlines and adhere to the daunting requirements handed them. Operators will continue to look to x86 blades and LAMP to slash their costs and ease their server consolidation/unification efforts. Architects are looking to SOA -- not Java -- to integrate their businesses goals and IT assets on the higher planes of process productivity, process extensibility, and IT asset value repeatability.

So Java remains a necessary and essential ingredient, for sure (for years) but no longer is Java the driving force for major platform or development decisions. It is legacy. It is a boon to middleware functionally (not necessarily economically any more), and is increasingly buried inside the middle of the middle of the stacks, and lives there increasingly out of mind.

While developers and operators are motivated by different imperatives -- Java is not what's guiding them to the future, it's what brought them out of the past. SOA may very well make Java less relevant on an accelerating time frame.

3) Gosling can chat up Creator and Java-AJAX synergies all he wants, but that does not bridge the gulf between the popularity and community investment curves between NetBeans and Eclipse. Just when Sun makes Java development easier, they make the open source framework choice complicated.

IBM did to Sun with Eclipse what Sun did to IBM with Java (except that IBM went open source and Sun did not). Sun needs to face this and stop pushing on the string that is NetBeans. I'll take Berlind's side on the bet. Sun's better path to developer uptake and architect appeal to promote Java infrastructure choices by the operators is to use AJAX et al as a wedge to drag along Sun's tools and possibly their platforms. NetBeans is not going to polish the edge of the market wedge, but leaves it dull instead.

Editorial standards