Part of this benign oversight came from the fact that, even as Java grew in popularity, Sun did not have a serious financial stake in the Java middleware market.

"When Sun started off with Java, it defined a [Java 2 Enterprise Edition] stack, but didn't really have an implementation outside the reference implementation. It wasn't competing against the likes of Hewlett-Packard, IBM or BEA Systems," Little said. Only when the company ramped up development of its Glassfish application server did the JCP Standard Edition/Enterprise Edition committee started to feel heat from Sun.

And this undue influence may only grow more pronounced under Oracle, Little suggested. Oracle has a thriving Java middleware business, bolstered by its 2008 of BEA, which offered the . Red Hat offers a competing application server and supporting software, called the Enterprise Application Platform.

"Oracle has a pretty good track record of making a business out of what it acquires," Little said. He speculated that Oracle could make it onerous for Java middleware competitors, by charging for the use of specifications, or rejecting a claim that a product is Java-compliant.

Little admitted that, "There has been no indication from Oracle that any of this is in the cards. It's a worst-case scenario." Thus far, Oracle has been an active contributor in the JCP, and has actually pushed for more openness in the development process.