The OP is actually quite lucky. I still have to support 1.4 installs.
But what's the worst: If you tell these IT departments to maybe update, they tell you that updating would pose a security risk which is ridiculous when you consider what's out there and actively targeting all JVMs younger than 1.6u27
I would think IT departments would be more concerned with the cost of regression testing applications with a new piece of infrastructure. Same as with IE6. I've not come across an IT organization that wouldn't love to upgrade to the latest piece of kit, IF their customers were willing to pay the cost - remembering that much of the cost will be in terms of repaying technical debt incurred by short-sighted decisions to skip best practises (coding to standards, producing documentation, refactoring, ...)
More appropriate would have been to say that JVM 5 is the new MSVC6.
MSVC6 is the compiler that killed C++. It did not support many features from the C++98 standard. Many projects were written for MSVC6 or earlier and did not start using new language features to keep MSVC6 compatibility.
I think the analogy is a little misleading, considering that the IE family is "choose one" but the JVM permits independent installations (most JVM products have gone so far as to just ship with the JRE bundled with their product).
the point of the article is that, whether its supported or not, enterprises still continue to use it. It is similar in regards to IE 6 that MS itself has campaigns to tell enterprises to switch from IE 6 (http://www.ie6countdown.com/), but they still continue using it.
IE6 is still a supported product so if there are issues people can get help. Most people in enterprise will choose a supported over unsupported product. Actually, I'm not sure why anyone wouldn't.
I understand the point, but the difference is that enterprises couldn't move away from IE6 for years since that was the latest one. In the meantime, it got so entrenched that it was very hard to move on.
Java 1.6 was released soon after 1.5, so companies that decided to stay with 1.5 are at fault, not Sun (now Oracle), which provided them with the fully compatible upgrade path.
Correct me if I'm wrong, but I was under the impression that current dynamic JVM implementations had relatively similar performance to newer JVM versions, so for some that use the JVM for specialized parts of the application i.e. app engine, than wouldn't some of the changes be insignificant from a performance standpoint?
You're right, I've never heard of backward compatibility that didn't work flawlessly. I know very little of Java, but if the backward compatibility isn't perfect then I could understand why companies would be hesitant to upgrade.
the java bytecodes remain unchanged from jvm 5 to 6. The bytecode is all the jvm sees. Thus the backward compatibility does work almost perfectly. Also jvm 6 has been out for long enough now to have ironed out any potential issues if there existed any in the first place.
There have been regressions over the years. Just because it is intended to be backward compatible doesn't mean there aren't occasional bugs that can break an application running on top of the JVM.
But what's the worst: If you tell these IT departments to maybe update, they tell you that updating would pose a security risk which is ridiculous when you consider what's out there and actively targeting all JVMs younger than 1.6u27