Report: Aging Java Components To Blame For Massively Buggy Open-Source Software

itwbennett writes: The problem isn't new, but a report released Tuesday by Sonatype, the company that manages one of the largest repositories of open-source Java components, sheds some light on poor inventory practices that are all-too-common in software development. To wit: 'Sonatype has determined that over 6 percent of the download requests from the Central Repository in 2014 were for component versions that included known vulnerabilities and the company's review of over 1,500 applications showed that by the time they were developed and released each of them had an average of 24 severe or critical flaws inherited from their components.'

Comments

Is this unique to Java?

[gstoddart]

I'm betting if you have a large enough pool of open source things, which depend on other open source things, then the bugs in the dependencies will trickle up to the projects which rely on them.

Though, admittedly, Java has also made this more annoying -- a decade or so ago when I was actively working on a Java project, it always amazed me how a new version of Java could completely break everything and then you'd have to re-test and re-certify everything.

It got to the point we put in very large bold characters in our release notes ... we work on this version of Java, if you get clever and introduce your own version of Java, we won't talk to you until you confirm the bug in the version we support.

A surprising number of clients were willing to blaze trail with whatever version of Java came along, and then kept expecting we'd be supporting custom versions from vendors or features which didn't exist when our version was built.

Eventually we learned to dread a new release of Java. Because invariably things went to hell and stopped working.

Re:Is this unique to Java?

[Daniel Hoffmann]

Yeah this is a common problem in pretty much all platforms, what makes Java stand out is too many Java things are actually specifications, not implementations. It kinda mixes all the headaches of conventional development (dll hell, outdated libraries, testing against multiple hardware/OSs) with the headaches that developing for browsers have (multiple implementations of the same specifications). One of the things that make people like the Spring is that, unlike J2EE, Spring is an implementation, not a specification so it usually works is you change your application server for example. Well some parts of Spring relies on Servlets, which is a specification, but Servlets implementations are ok (although Java6 does not support Servlets 3.0 which is a pain in the ass if your client is on Java6 and refuses to update).

Accept the fact

[cloud.pt]

It's about time everyone stops whining. There are things in life you're better safe than sorry, but then there are things in life you just can't change: not every single entity can keep maintaining what they create. Human beings are limited, and so are human organizations - they lack money, workforce or simply the patience to put up with some "critical flaws" that are just too rooted in bad design to be solved without a restructuring.

THAT IS THE REAL FLAW.

There are good ways and bad ways to create reusable components. Black boxing (containing) everything for starters (sans the closed-sourced part) is something people tend to limit the scope to testing and/or to services outside a fully-fledged system's component border. Technologies like SOA are just one of many ways to plug&play every new piece of technology that performs a very specific task in a different way of a previously flawed one. Think project Ara. It's not only fun to develop like this (although some have problem conceptualizing it), but it's also more robust in the long run. Using such paradigms is what we, as the "clients" of such "aging and flawed" components can do push better development of individual components.

Now, each and every component developer has to find ways to keep their work atomic, so as to not conflict with the principles of technologies they are developed to work for. This might all seem like an utopian way of what to expect of the coding community, but then again we are also still looking for the best ways to apply near-perfect political views designed hundreds of years ago, which are yet to achieve full potential. I keep my hopes up for both issues, but my expectations low.