• Article

{ End Bracket }

Microsoft Java Virtual Machine Update

Brian Keller

Contents

Step 1—Understand the Dependencies
Step 2—Determine a Migration Strategy

In a settlement agreement reached in January 2001 to resolve a dispute over the Microsoft distribution of its Java implementation, Sun Microsystems and Microsoft agreed to limit the duration of the time Microsoft would use Sun's source code and compatibility test suites to support the Microsoft® Java Virtual Machine (MSJVM). However, as part of the April 2004 settlement agreement, Sun and Microsoft agreed to extend the Microsoft license to use Sun's Java source code and compatibility test suites. This extension allows Microsoft to support the MSJVM and address potential security issues until December 31, 2007.

The MSJVM is being phased out of all current Microsoft products and will not be included in any future products. The MSJVM is obsolete code and will no longer be enhanced or developed. Microsoft will only continue to provide security fixes to help keep customer machines secure.

Sites and applications that currently depend upon the MSJVM will not function correctly when accessed by systems that do not have the MSJVM installed. Microsoft recommends that customers using Microsoft Visual J++® and the Microsoft SDK for Java who have built applications or Web sites that use the MSJVM begin identifying MSJVM dependencies and transition to an alternate solution. For customers who choose to pursue a solution supported by Microsoft, the two migration options are Microsoft Visual J#® .NET and the Microsoft Java Language Conversion Assistant. These products assist developers in migrating existing source code to the .NET Framework.

Step 1—Understand the Dependencies

The first step in eliminating dependencies on the MSJVM is to identify those dependencies. The following are examples of products or applications that may contain dependencies:

  • Internal applications, such as payroll software
  • External applications, such as those sold by ISVs
  • Internal applets, such as those used on a corporate intranet site for employee benefits and the like
  • External applets, such as those accessed by partners, vendors, or customers, or applets that your company relies on which are provided by a third party

Microsoft provides the Diagnostic Tool for the Microsoft VM to help detect such dependencies. To download this diagnostic tool, visit https://www.microsoft.com/java.

Step 2—Determine a Migration Strategy

Once you develop a list of the applications and applets which rely on the MSJVM, the next step is to determine a migration strategy for those components. Microsoft provides several supported tools for migrating MSJVM-based applications, and there are third-party solutions available as well. A summary of some of these options follows.

Visual J# .NET This can be used by developers who are familiar with the Java-language syntax to build applications and services on the .NET Framework. It integrates the Java-language syntax into the Visual Studio® .NET integrated development environment (IDE). Visual J# also supports most of the functionality found in Visual J++ 6.0, including Microsoft extensions such as WFC. J# Browser Controls is a complementary library which provides support for migrating applets.

The Java Language Conversion Assistant JLCA converts Visual J++ 6.0 projects and Java-language files to Visual C#®. By converting these files to Visual C#, you can utilize the existing code base and take advantage of the benefits of the .NET Framework.

Alternate rendering technologies DHTML, ECMAScript, VBScript, JScript®, and others are also viable options for applet migration. These technologies can implement most simple navigational items (for example, menus, rollovers, simple calculators, and chat clients) and are an option for converting low to medium complexity applets dedicated to navigation and user interface tasks.

Third-party Java Runtime Environments These may also be an option. Be aware that these solutions are not supported by Microsoft. Depending on the amount of MSJVM-specific dependencies within the application (for example, WFC, JavaCOM, ms.*), there may be varying degrees of manual conversion that you will be required to perform.

Retiring the application This may be an alternative solution depending on your business requirements.

Detailed information on all these migration strategies can be found in the MSJVM Migration Guide for Developers at https://www.microsoft.com/java.

The MSJVM will reach the end of its life on December 31, 2007. You should be taking steps now to eliminate your dependencies on the MSJVM. By acting now, you can adequately prepare for any migration complexities and can begin taking advantage of fully supported runtime alternatives.