Randy Heffner from Forrester has an opinion piece on CNet regarding the JCP and JSR-215, which would help to make the JCP process more transparent. After he finishes his explanation of how the new JSR can help strategic technical planning, he writes.

Still, in competing with the Microsoft platform, Java's biggest disadvantage is not having a unified and efficient way to bring the diverse set of Java community plans, ideas and goals together into a coherent plan that explains the necessity of and relationships between the many different JSRs.

A bit later he writes:

It would be a fatal weakness if, as Java vendors compete for market share both among themselves and against Microsoft, the need for innovation combined with the slowness of the standards process and the lack of a coherent direction resulted in a preponderance of proprietary features over standard features in Java implementations.

After all of that, he doesn't actually talk about the role of a chief architect. He hints at it in his first quote, where he talks about a coherent plan of relationships among the various JSR's. But there's another aspect of an architect's role that he is overlooking. Frequently the architect is the one who says no to the raft of interested parties trying to get stuff into a project. The reason that Java is suffering from a huge number of poorly related JSR's, is that all the vendors are trying to get an edge on each other by slipping their product into the JCP as the basis for a JSR. IBM and Oracle did it this week with an XQuery API -- how can we have an API for something that itself hasn't been standardized? If Java needs an architect, it needs one who will say no.

There's one other point that Heffner misses. The point of avoiding proprietary API's is to avoid lock-in. You don't want to be locked in because you're at someone else's mercy. There is another way to control your own destiny. Community developed open implementations.

If Java gets into the all together, highly integrated platform game, then it is playing the same game as Microsoft, but with a deck that's stacked badly against it. Java technology and the CLR are both technologies that allow more modular development than previous technologies. There are three models you can compare and three dimensions to compare them.

The three models are:

• Java-JCP - the existing Sun big-bang JCP, J2SE, J2EE
• Java-Open Source - Java + open source extensions
• CLR-MS - the centrally planned Microsoft .NET

You could even add a fourth model, CLR-Open Source, that would be represented by Mono, but that's for another post, perhaps.

The three dimensions are, What is the process for platform evolution, how often does the platform evolve, what is the reputation of the platform vendor in the developer and customer communities?

For Java-JCP, the process is the JCP, how often is roughly 18 months to 2 years, and the reputation is Sun's reputation, and to a lesser extent, that of IBM, BEA, and whoever else you'd like to lump in there.

For Java-Open Source, the process is developers scratching an itch, how often is as often as possible, and the reputation is the varied reputation of different parts of the open source community

For CLR-MS, the process is MS .NET engineering, how often is roughly 18 months to 2 years, and the repuation is Microsoft's reputation

The big difference between Java-JCP and CLR-MS is JCP vs MS .NET engineering. I'd like to have something much more nimble.