Java's extremely dynamic binding did not save it from problems resulting from stale versions.
It's normal for enterprise environments to be a few versions of Java behind. Some of the build tools, like Maven, encourage this anti-pattern by allowing people to specify library dependencies on specific versions. In fact, I think it issues a warning message in some cases if you fail to specify an explicit version dependency.
The underlying problem is that there's no concept of a version number API in Java. In C there are library name conventions that allow you to ask for the newest version of the library that implements a given API. But Java never developed those conventions, so your only safe course of action is to peg to a specific version.
By the way, JDK7 is still considered new and untested by most enterprise Java users. I don't even have it installed yet because what would be the point? It's still experimental in the context of Hadoop.
Another thing to note is that there are going to be a lot fewer security issues in managed code than in C/C++ libraries. I enjoy programming in C and C++, but let's not kid ourselves. I think Go's model is fine. If there's a big security flaw discovered in some Go library, it will trigger a lot of binaries to be re-downloaded from Linux distros. But I don't expect that to happen that often.