Oracle should relax Sun's Java Community control grip
'No-brainer' open-source vote winner
Less Process, more visibility
There is another problem for Oracle, and for Johnson, it's in an area where he believes Sun could have made more progress and Oracle can go further: making the JCP open and transparent. Making the JCP more like an open-source project, which can attract the kinds of community members where innovation in programming and in Java are really coming from today.
The problem with the JCP today is the majority of those leading the specs that go into new versions of Java are led by Sun employees, and it's down to the spec leads how much information they share with other members of the JCP on the technology and progress.
This closed process has not only turned off potential participants from the open-source community. The process has, according to Johnson in the past, damaged Java by creating specifications that are designed by committee rather than being of genuine use to the industry.
Johnson's company SpringSource voted against Java EE 6.0 in March, with Apache, saying the process that bred it had led to the inclusion of new and untested features that risked introducing braking changes to enterprise Java.
Johnson believes Sun's also used this approach to bolster its own Java middleware at the expense of middleware from IBM. Java specs, for example, were implemented sooner in Sun's GlassFish application server that other application servers. GlassFish was also anointed by Sun as the industry's official Java application-server reference implementation.
Not that this really helped Sun's middleware in the remotest on market share or paying customers. But it did rob the process of participants who could have helped build Java specifications developers wanted and could really use.
"If Oracle attempts to exert the level of control Sun has exerted, that will cause people to lose faith in the JCP," Johnson said. ®
Sponsored: DevOps and continuous delivery