First posted to MSDN on Apr, 26 2011
One of the things I notice quite a bit with the customers I work with is that they have this tendency to mitigate the risk of applications breaking by changing as little of the platform as they can.
One of the areas where this strategy is challenged is when security updates aren’t distinguishable from application updates. Such is the case, frequently, with Java. Like all other aspects of the platform, people love to hard code version checks into applications, and the fail if you don’t get precisely what you expected. So, you end up freezing in a version within a Java platform series.
This is problematic for several reasons.
The first is security. Here’s what the Microsoft Malware Protection Center has to say:
Have you checked the Java?
The second is, surprisingly, compatibility:
Error in Internet Explorer 9: "We were unable to return you to <your webpage>, Internet Explore...
As it turns out, some older versions of Java don’t run well with IE9. I won’t go into all of the gory details, but I’ll just sum it up by saying that it is (to me) a completely forgivable error: the developers chose to do something which probably would have been OK with straight C++, but which is against the rules with COM. Since COM is one of the most subtle and complex platforms ever created (as anecdotally indicated by the number of subtle bugs I come across) I’m willing to let that slide, they fixed it really quickly, but it does mean that you have to get a new one.
So, if you are planning an upgrade to IE9 (which I recommend), then you’ll also want to plan an upgrade to Java as well (which I already recommended, but now you have two reasons). You may surface a number of issues with hard coding, but for security reasons, it’s really important to remove those obstacles anyway.
