Chapter 3: Available Transition Options

Article
12/05/2007

This chapter provides a brief summary of the possible solutions available for transitioning from the MSJVM. Developers will need to refer to the Microsoft Java Virtual Machine Migration Guide for Developers for more in-depth information regarding migration to .NET, other rendering technologies, and alternate JREs.

In the early stages, it is a good idea to set up a pilot project that provides a proof of technology. This project should contain samples of each type of applet to be converted, and should be restricted in scope.

From an organizational point of view, there are great benefits to choosing a single solution: it is easier to scope all of the work and minimizes the number of new skills required. On the other hand, mixing implementations may increase the amount of work required, but may accommodate your needs. Try testing different transition options to understand which one is best suited for your applets and needs. Regardless of the solution or solutions you decide upon, be aware of all planning issues and organizational impacts.

For most, a successful transition is one that results in “clean” systems without any MSJVM dependent files and applications, and with the MSJVM removed. However the definition of a “clean” system is based on your decision. If you are satisfied with simply removing the MSJVM, then once you have accomplished that goal you are finished. If you want to initiate a full scale migration project of every application with a MSJVM dependency to a .NET environment or install an alternate JRE, then once you have completed that goal you are done. At minimum your goal should be to identify MSJVM dependencies, and aside from any transition option you may choose, lock down security.

Remove Applets

Some applets do not add significant value to the web page, or the value added is not sufficient to justify developing replacements. If the applet can be removed without significant harm to the page, or if the entire page can be removed, consider removal as an option. This is done by removing the <APPLET>...</APPLET> text or commenting it out.

Advantages. Easy to implement, easy to test.
Drawbacks. Usually some loss of functionality on the page.
Deployment considerations. None beyond deployment of files.

Lock Down Security without Altering Applications

For some applications you may consider continuing to use the MSJVM. Legal licensees of Visual J++ 6.0 and the Microsoft SDK for Java may continue distribution of the MSJVM as part of the runtime for their application in accordance with the terms of their Microsoft Software License Terms, or they may decide not to remove the MSJVM from locations where it is already installed. As mentioned earlier, leaving the MSJVM in place is not recommended as it may expose the system to potential security risks.

However, Internet Explorer (IE) contains security settings that can be used to disable or restrict the applicability of the MSJVM. You can choose to turn off the MSJVM for all websites. You can also elect to continue using the MSJVM but reduce any future security issues by limiting use of Java to specific sites. After turning off Java in the Internet zone, depending upon the policy of your site, users or administrators can turn on Java for all trusted sites and then add the specific sites on which they want to support applets by including them in the Trusted Sites list.

Appropriate applications for this solution may be those that have low use or are near the end of their life cycles, and have a restricted user base or a user base that has no concern about possible future security issues. For example, an older application that will soon be obsolete but needs to be kept for future support or maintenance concerns might be isolated in a security lockdown.

Advantages. Inexpensive.
Drawbacks. Done on client machine, and therefore best suited for intranets; may reduce, but not completely eliminate, possible future security risks.
Skills requirement. Requires knowledge of organization’s network security policies and procedures.
Deployment considerations. Security lockdown is on each end user’s computer. Depending on your network configuration, IT may be able to set this as a Group Policy or propagate the settings through login scripts and .reg files.

Migrate or Rewrite Applications

Migrating or rewriting the code to another solution can often provide identical functionality to current applets and applications, and provides higher security. For example, migration to .NET allows you to take advantage of the power of the Windows platform. Applications in .NET are easy to extend and integrate well. By migrating to a .NET environment, support issues remain with Microsoft.

In some cases, business needs require a cross-platform solution where a .NET strategy is inappropriate. In this case, you have at least three options:

DHTML
Rewriting the application or applet for another display technology such as Flash or Shockwave
Installing an alternate JRE

For more information regarding the migration or rewriting of applications refer to the Microsoft Java Virtual Machine Migration Guide for Developers.

Migrate to .NET and Visual J# (J# Browser Controls)

A Java applet or application can be upgraded to Visual J# by compiling it to a managed library using the Visual J# compiler(vjc.exe). If only the bytecode (.class files) exists for the Java component, the Visual J# Binary Converter Tool(JbImp.exe) can be used to convert the component to a managed library. When migrating an applet, the J# Browser Controls runtime is required in addition to the J# compilers.

Compiling a Java applet to a J# Browser Control usually does not require any changes to the Java applet source code. The J# Browser Control runtime provides support for functionality equivalent to most JDK 1.1.4 level packages, including the java.applet package.

Advantages. Microsoft supported conversion. Speed of implementation, and reuse of existing Java code.
Drawbacks. Automated conversion may still require some rewriting of code.
Skills requirement. Requires knowledge of .NET Framework and Visual J#.NET.
Deployment considerations. Migrated applets are installed on the Web server and called J# Browser Controls. The end user must install both the .NET runtime environment and the J# Browser Control runtime environment. Migrated applications behave just like regular applications, and require the .NET Framework and J# Redistributable to run.

Migrate to .NET and Visual C# (JLCA)

A Java applet or application can be rewritten in Visual C# using a tool such as the Java Language Conversion Assistant (JLCA). Often the JLCA converts more than 90% of the code automatically. The remaining code must be converted manually.

Advantages. Microsoft supported conversion. Access to the native .NET APIs and complete integration with .NET. The use of automated tools makes this a reasonably fast conversion. Applications converted are often faster and smaller than they were originally. Future extensions are possible that make use of the entire .NET Framework. Use of Windows forms and interface supports sophisticated user interfaces.
Drawbacks. Automated conversion still requires some rewriting of code.
Skills requirement. Requires knowledge of .NET Framework and Visual C#.
Deployment considerations. Migrated apps are installed on the Web server. The .NET runtime environment must be installed on each user’s machine.

Use an Alternate Rendering Technology

Alternate rendering technologies including, DHTML, Flash, VB Script, Java Script, ECMA Script, etc. are also options. These technologies can implement most simple navigational items (for example, menus, rollovers, simple calculators, and chat clients). These are a good choice for converting low to medium complexity applets dedicated to navigation and user interface tasks.

Advantages. Significant speed advantages are achieved because the applet and JRE do not need to be loaded. Cross-platform compatibility is maintained.
Drawbacks. Not for rich applets or for extensive data manipulation and requires complete rewrite of applet code. Testing for each browser-platform combination can be time-consuming. Alternate rendering technologies are not supported by Microsoft and may require you to establish new support contracts with the appropriate vendor.
Skills requirement. Requires knowledge of the appropriate coding language.
Deployment considerations. Migrated files are installed on the Web server. Availability to end users could be an issue for plug-ins and may require installation on each client.

Use an Alternate JRE

The Java applets or applications may run on an alternate JRE. Examine and test the possible JREs carefully because different virtual environments may implement different versions of the Java standard. If this is an external (Internet) facing site, each applet should contain a reference to where users can obtain the runtime. You may also want to make the choice to download the JRE explicit instead of referring to it in the <OBJECT> tag itself.

Advantages. Substantial Java code reuse, although some changes are still required for some applications.
Drawbacks. All systems need to download the selected JRE. Different JREs implement different versions of the Java standard. This solution increases complexity of support because problems must be routed through another vendor. If for some reason there are multiple Java runtime environments on a PC, you will need to explicitly point to the correct JRE and version to ensure that the applet runs correctly. Alternate JREs are not supported by Microsoft.
Skills requirement. Requires knowledge of Java implementations.
Deployment considerations. Web files may need to be updated to point to a new JRE; end users will need to upgrade their Java runtime environments.

Note Although Microsoft cannot vouch for the security and reliability of solutions offered by other companies, non-Microsoft solutions are available. Customers choosing to explore such solutions should engage in testing prior to pursuing this migration path.

Download

msjvm_itpro.pdf

Get Adobe Acrobat Reader