Mitigate Java Virtual Machine risks

Thanks to the 2001 Sun/Microsoft settlement regarding their legal dispute over the use of the Java Virtual Machine (JVM) in the Microsoft environment, many corporations may be facing a problem of Y2K proportions. In fact, many companies may not even know that they’re at risk because they’re not aware of the level at which they’re using the technology that puts them there. Let's look at the source of the potential problem and ways that you can mitigate or eliminate it in your environment.

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 organization 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 January 1, 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.

Mitigation options
After you understand the level at which you’ve become dependent on the Microsoft VM, you have several options for mitigation. The first, and most commonly adopted solution, will be to move off the Microsoft VM and onto another company’s Java VM. Companies that are heavy adopters of Java and J2EE technologies have probably already chosen a non-Microsoft VM and used that VM in their production applications. But many companies that use both Microsoft and J2EE technologies may have chosen to stay with the Microsoft VM. They'll now need to look at mitigation strategies that may include the replacement of the Microsoft VM with another company’s VM. The other mitigation strategies involve removing the dependence on any version of the Java VM.

For client applications that rely on Java applets, you have two options for removing the Java dependency. First, rather than using Java applet technology, companies can use alternate technologies like DHTML, Macromedia Flash, or other client rendering technologies. Second, Microsoft has released the beta version of its J# browser controls (JBC), which allow companies to migrate existing applet code to J#.NET and run the client-side applications using the .NET Framework instead of the JVM. Of course, for either of these options, you’d have to have access to the Java source code to effectively migrate the client functionality.

If you don’t have access to the source code, you can at least mitigate some of the client security risks by using the security zones features of Internet Explorer. This feature will allow you to limit the use of the Microsoft VM to specific sites and keep general Internet sites from accessing, and potentially abusing, the Microsoft VM. If you anticipate using Java on the client for the long term, consider either migrating the code to another technology or replacing the Microsoft VM with another vendor’s JVM.

Most companies that have implemented J2EE and Java technologies on the server have already chosen to use the JVM recommended by their server tools vendor. If you have used the Microsoft VM in a server installation in your environment, you should either move the application to a different JVM or migrate the application from Java to .NET using Visual Studio, depending on your company's chosen technology direction.

Support from Microsoft
Microsoft will be releasing transition and migration tools as well as processes and guidance for consulting firms and software developers who need to provide these migration services to their customers. MSDN.com will be Microsoft’s primary distribution mechanism for these tools. Some of the tools are already available from the site in beta format. For example, Microsoft recently released the Microsoft Virtual Machine Transition Guide, which will give detailed information through various options for making the transition. To help customers understand where they may have dependencies on the Microsoft VM, Microsoft will be posting a new tool called the Microsoft Diagnostic Tool for the Microsoft VM.

To help customers recompile Java applets to run on the Microsoft .NET Framework, Microsoft has released the beta version of the J# Browser Controls and will deliver a final release this fall. If you have a large number of Java applications and you’ve made a corporate decision to move toward Microsoft .NET, you can also take advantage of the Java Language Conversion Assistant 2.0 (JLCA), which is designed to help you move complete Java applications en masse over to the C# language.

TechRepublic originally published this article on 26 August 2003.