Java security updates continue to flow like water. The most recent patch included multiple, significant design changes to counter vulnerabilities, but the preceding sequence of fixes has been just as significant. As several commentators were saying at the start of the year, the security problems uncovered in Java are hard to fix because they arise from fundamental design decisions, especially regarding the code that supports browser-based use of Java.
What worries security researchers is the cascade of interacting subsystems that are implicated. The problems seem to be less a defect in a single subsystem and more a consequence of the interplay of apparently correct subsystems. Oracle has been working very hard to address the issue, and it deserves kudos on this front. But the developers I've consulted note that while Oracle's fixes have broken the exploit chain for multiple avenues of attack, building new chains of exploits remains possible -- and keeps happening within the shadows of the black-hat cracker community who are fast to exploit every avenue for attack.
[ Also on InfoWorld: Why fixing the Java flaw will take so long | How to disable Java in your browsers | Track the latest trends in open source with InfoWorld's Technology: Open Source newsletter. ]
Oracle's Java technical chief recently admitted that dealing with long-standing security issues has hampered the release of the latest Java installment: "As a consequence of this renewed focus on security the Java 8 schedule, with a GA release in early September, is no longer achievable."
It goes back to Sun
The issues didn't necessarily originate with Oracle; they've been accumulating over many years, first at Sun and then at Oracle. The problem has been that until now these issues have been on a continual back burner, the "tyranny of the urgent" focusing developer attention on business considerations as the priority.
I've discussed this with many people -- including key figures on the Java development team, past and present -- and they all say this is the inevitable consequence of a longtime "technical debt" in Java. The problems could have been exposed long ago when Sun was in charge, but the Sun team stayed lucky for long enough to dodge the bullet.
Dealing with this technical debt is a time-consuming affair, but eventually it catches up with a project and needs to be addressed. Some veteran projects don't seem to suffer as much from this sort of flotsam, though -- and the key is in the community. Proprietary projects are often forced to be solely feature-focused, prioritizing customer needs and marketing schedules over the gruntwork of keeping the code clean. Open source projects with a large and healthy community are in a much better position to bypass the problem of technical debt, as community members will often pour enthusiasm and expertise into resolving the backlog.
How LibreOffice handled its technical debt
Let's take a look at the case of LibreOffice. When the project forked, it inherited a large technical debt from OpenOffice. The Document Foundation's blog says this came from "a 15-year-old code base, where features were not implemented and bugs were not solved in order to avoid creating problems." Now, though, the community of developers felt much more fully in control of the direction of the software.