How to mitigate Java Virtual Machine risks

The problem
One of the terms of the settlement was that as of January 2004, Microsoft would no longer be able to make any changes to its version of the Java Virtual Machine. If your organisation has been implementing Java solutions based on non-Microsoft versions of the JVM, this shouldn’t have any effect on you. But many corporations have relied on the version of the JVM delivered with earlier versions of Internet Explorer for their Java deployment environment. In these cases, you should start considering how you’ll mitigate any future risk.

Even if you do nothing, you may still not find yourself at risk. Microsoft removed the JVM from Windows XP and has not been shipping it with updates to Internet Explorer or with any other of its products for well over a year. Moreover, Microsoft has been releasing security patches for the current (last officially released) version of its VM. But given that Microsoft will not be allowed to patch any security holes after 1 January, 2004, your best bet is to make changes now that will remove any dependencies that you have on the Microsoft VM. So how can you protect yourself?

Mitigation strategy
The first step in any mitigation strategy is to understand at what level you are dependent on the Microsoft VM. For example, do you have production applications written in-house using Java that require the presence of the Microsoft VM on either the client or the server? Do you have client tools that use the Microsoft VM? Do you have commercial applications that have been delivered and installed that rely on the Microsoft VM for server processes or for Java applets that run on the clients? Many companies will discover dependencies of which they were not aware. Once you’ve discovered the dependencies, begin developing a transition plan and plotting your migration path. Finally, start your migration and testing. Given the short window between now and January 2004, this must be a major priority for someone in your IT department.