Java Under Oracle: Unity, But No Apache Vitality - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Government // Enterprise Architecture
09:28 PM
Charles Babcock
Charles Babcock
Connect Directly

Java Under Oracle: Unity, But No Apache Vitality

While Oracle has imposed order and unity in a contentious Java community, at what price has it come?

Oracle, in the post-Sun acquisition era, can be relied upon to sustain the long-term development and independence of Java -- up to a point. It has to. Its next-generation Fusion applications will be written in Java. With that said, however, Oracle is also capable of foreshortening Java's future in ways it may or may not understand.

Oracle will support open source procedures and goals as long as they are aligned with Oracle's business interests. If they're not, it will do something else, including walk on those previously honored procedures and goals. In the past, I might have contrasted this approach with that of IBM, which adopted an early and principled approach to supporting open source code. It was an early adopter, for example, of the Apache Web Server in its own product line. But I can't say that today. In the long run, I think IBM's approach is not so different from Oracle's. It will support open source as long as it is in its strategic interest to do so. When its interest changes, it does something different.

This leads me to the involuntary conclusion that open source code and large proprietary companies are contrary and incompatible things; no matter how much the one wants to support the other, they are at odds and the one inevitably undermines the other. Let's come back to that.

Let me say right off the bat that Oracle has done many things right with Java. It inherited a divided and stalemated Java Community Process that Sun, preoccupied with survival, couldn't move off of its stall point. I know some Java advocates felt the language had become too unwieldy. And there was a long festering dispute with the Apache Software Foundation over whether its Harmony implementation of the Java spec could be certified as 100% Java.

Sun didn't want to allow such a development, for competitive reasons. Allowing Apache's work to be certified would have generated a new round of Java competitors that Sun would have no means of licensing or controlling. Under the Apache license, they would nevertheless still bear Java's Good Housekeeping seal of approval.

Logical Outcome

Oracle argued on behalf of the Apache position prior to its acquisition of Sun, knowing that a second, independent Java in the marketplace was a guarantee of Sun's good behavior. IBM helped found, funded, and contributed heavily to the Apache Harmony project for the same reason. But once it gained ownership of Java, Oracle changed its mind. What's more, it's now clear it also skillfully coaxed IBM into changing its mind as well. The two are now positioned as co-guardians of the one true Java, embodied in the OpenJDK, held firmly under Oracle's control.

That might seem like a logical outcome, but it was by no means assured. To IBM, Sun had been mercurial enough, with constant tension between the two over a technology they both relied upon. Imagine IBM's discomfort as its own negotiations to acquire Sun failed in the spring of 2009 and Oracle stepped to the fore. If Sun had been a difficult Java partner, Oracle was an unpredictable, 500-pound gorilla with whom a fight might break out at any time.

IBM is a licensed Java user, but that meant at some point, Oracle would be in a position to review its renewal. If IBM was crowding Oracle too hard in a favorite market, say Java middleware where they compete head to head, Oracle could decline to renew its license. With no license, a Java vendor doesn't have access to the thousands of software tests that establish the 100% Java compatibility of its product. IBM could produce reliable Java without access to the tests, but without certification a Java product could be labeled by an aggressive competitor as "unproven" or even "incompatible."

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
1 of 3
Comment  | 
Print  | 
More Insights
InformationWeek Is Getting an Upgrade!

Find out more about our plans to improve the look, functionality, and performance of the InformationWeek site in the coming months.

11 Things IT Professionals Wish They Knew Earlier in Their Careers
Lisa Morgan, Freelance Writer,  4/6/2021
Time to Shift Your Job Search Out of Neutral
Jessica Davis, Senior Editor, Enterprise Apps,  3/31/2021
Does Identity Hinder Hybrid-Cloud and Multi-Cloud Adoption?
Joao-Pierre S. Ruth, Senior Writer,  4/1/2021
White Papers
Register for InformationWeek Newsletters
Current Issue
Successful Strategies for Digital Transformation
Download this report to learn about the latest technologies and best practices or ensuring a successful transition from outdated business transformation tactics.
Flash Poll