Oracle's closed approach keeps Java at risk

Oracle's whack-a-mole with Java security follows a decade of technical debt. But why won't it turn to open source community for help?

Page 2 of 2

The result has been investments in the code that would never have been possible back in the days when Sun's management was pulling the team in different directions every six months. Some are very mundane; translating tens of thousands of comments from German to English has opened up the code for collaboration by developers with English as a second language, for example. Others are more significant -- support for defunct operating systems has been removed; the object model has been refactored; the mechanism for dialog layouts has been brought up to date. Some of the improvements have pioneered new QA techniques, like the "binary bisect" devised to allow rapid resolution of regressions.

The LibreOffice community has chosen to invest many hours eliminating that debt, yet it still found the time to work on significant new features. There are a lot of them, including more substantial features such as Microsoft Works Import filters, as well as support for Visio, Microsoft Publisher, and CMIS.

Should Oracle be reassured by the move to open source Java? So long as it is able to keep to its community commitments with OpenJDK, this investment in dealing with the technical debt could be a one-off payment, allowing Java to be developed unhindered in future releases. Red Hat's commitment to provide continuity for past OpenJDK versions can only help. Its decision to sustain OpenJDK 6 is a fruit of the opening of the Java code started by Sun. Being open source has enabled Red Hat to step into the project leader role vacated by Oracle. With the help of the OpenJDK community, Red Hat hopes to be able to keep the still widely used code maintained.

Oracle is its own enemy

Issues remain around security collaboration. Just as with MySQL, Oracle refuses to treat other community members as equals when it comes to security issues and has not formed an inclusive security team around Java. Instead, security issues are addressed in secret, with even the most trusted partners getting only a hint that work is in progress. Oracle then releases security fixes simultaneously to both end-users and community partners, giving no time to validate or integrate the changes. This lack of security collaboration is what drove both the Fedora and OpenSuse Linux projects (and others) to use MariaDB instead of MySQL, and it is just as much of a problem for the OpenJDK community.

Oracle's strong internal security staff continues to block any moves to open up by its open source projects; ironically, Oracle also suffers a cost of that intransigence. While the results of its security work will eventually be open, Oracle's approach means the burden of diagnosis, fixing, and testing continues to fall on the company alone. There's a vigorous discussion in the comments to the Java delay blog post, but it's focused on the task of fitting the features to the release trainrather than the cause of the delay.

The Java security debacle has probably been an unavoidable pay-down of long-term technical debt. But if Oracle persists in keeping matters closed going forward, future incidents will be inevitable.

This article, "Oracle's closed approach keeps Java at risk," was originally published at Read more of the Open Sources blog and follow the latest developments in open source at For the latest business technology news, follow on Twitter.

| 1 2 Page 2