It's ironic to speak of security, when you do static linking *all the time*.
Posted Oct 27, 2012 21:11 UTC (Sat) by cmccabe (guest, #60281)
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.
Posted Oct 28, 2012 16:29 UTC (Sun) by nix (subscriber, #2304)
The irony is that the original implementer of this feature (before GNU souped it up by adding default symbol versions) was... Sun, and it has stood them in very good stead over the years. I have no idea why on earth the Java people didn't learn from the people across the hall in this area.
Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds