• Chart: Pros and Cons of Java Migration Products

Microsoft has released a beta version of the Java Language Conversion Assistant (JLCA), a developer tool that translates source code written in Java to C#. The JLCA supplements the previously announced Visual J# product and is the final piece in Microsoft’s Java User Migration Path (JUMP) strategy. It simplifies the process of moving Java code to C# and offers an alternative to using Visual J#, which allows programmers to continue using the Java programming language for .NET.

The translation process is not fully automatic, however. In the long run, most customers will be best served by migrating from Java to C# programming, and those who make the migration need to be aware of the alternatives for making that transition.

JLCA Features and Supported Libraries

The JLCA is an add-in to the Visual Studio .NET integrated development environment (IDE), Microsoft's tool suite for professional developers. The add-in allows developers to select a Visual J++ project and produce a new project containing the translated code, while leaving the original files unchanged.

Translating a program, however, involves more than just translating code—it also requires translating APIs. In the case of the JLCA, it means translating Java APIs to corresponding .NET APIs.

The beta version of the JLCA supports only a subset of the Java APIs introduced in version 1.1.4 of Sun's Java Development Kit (JDK) in Oct. 1997. It also supports Microsoft’s own Windows Foundation Classes (WFC), which were part of Visual J++ (VJ++). WFC is an obsolete API and was not supported in any Microsoft product other than VJ++. In fact, one of the primary purposes of the JLCA is to help move WFC applications to a supported API.

The production version of the JLCA will add support for more APIs, including the Abstract Windowing Toolkit (or AWT, which is the base graphical user interface [GUI] library for Java), Java Database Connectivity (JDBC, a key database API), and Java Server Pages (JSP, a Web server API). However, developers use many other Java APIs, some more widely than others. The JLCA automatically creates a log file of all APIs being used by the application. Developers can send that list to Microsoft, and their input will help determine which additional APIs are included in the production version.

Translation Not Fully Automatic

The JLCA, like most conversion tools, is not fully automatic. Because language constructs and APIs can be used in so many different ways, most real-world programs will require developers to tweak the resulting translation, either because it uses an unsupported API or because of major differences between a Java API and the corresponding .NET API.

In addition, users of the JLCA will face the challenge of maintaining an application after it has been translated. Automatic translators typically do not generate the same kind of code that an experienced developer would write, which can make it difficult to enhance or fix bugs in the code as time goes on. This is made even more difficult if, as is common, the developer doing maintenance is not the same developer who wrote the original code.

JLCA Supplements Visual J#

Microsoft has another option for migrating Java applications to .NET—Visual J#, its Java language tool for .NET. (See "J# Brings Java to .NET" on page 11 of the Nov. 2001 Update.) With Visual J# nearing final release and the first beta of the JLCA now available, developers looking to migrate from Java to .NET face the following choices:

• Translate Java applications to C# and .NET with the JLCA
• Use Visual J# to stick with the Java language but use .NET APIs.

In the short term, using the JLCA requires a larger investment in time to get an application running than using Visual J#. Visual J# was designed to be able to recompile many existing Java applications without modification, particularly applications that use the WFC APIs.

However, Microsoft is unlikely to make any significant enhancements to Visual J#. C#, a major component of Visual Studio, is positioned as a competitor to the Java language and is widely used by development teams within Microsoft. Visual J#, on the other hand, is an add-on to Visual Studio; it was not developed by the core Visual Studio team and is rarely used within Microsoft. Finally, the key architect of the C# language, Anders Hejlsberg, is also the key architect of the .NET Framework. In sum, Visual C# is a strategic element of the entire .NET platform and will continue to be supported and enhanced while Visual J# probably will not.

In addition, it is unlikely that Microsoft will add support for any Sun APIs that compete directly with its own .NET initiative, nor will it continue to enhance its own WFC APIs.

Consequently, Visual J# should be thought of as an interim step toward the eventual conversion to C# and .NET, rather than a long-term solution for building and maintaining .NET applications.

Deciding How to Move Forward

Because J# is not a long-term option, companies that want to move to .NET must decide whether to use J# as an interim solution before migrating to C#, and whether to use the JLCA to make the eventual migration. What they decide will depend upon the type of application being migrated and the tool that was used to create it. The following scenarios describe the most promising migration options for common application types.

WFC and Visual J++. Both Visual J# and the JLCA are likely to work quite well with WFC applications created with Visual J++. Most WFC applications can be recompiled quickly with Visual J# to run on .NET. Thus, many companies will use Visual J# to extend the life of WFC applications. However, these companies must still plan to move away from WFC in the long term and should evaluate the JLCA as a more direct way to make that transition.

Sun APIs and Visual J++. The likelihood of success when using either Visual J# or the JLCA with Sun APIs depends on which Sun APIs are used. All Java applications use the core set of APIs that define fundamental data types, and both the JLCA and Visual J# support these libraries. They also both support the most common GUI library, the AWT.

However, there are a great many Java APIs, both from Sun and from third parties, and neither tool is designed to support all of them. Since both tools are currently in beta, Microsoft has not defined the exact set of APIs that will be supported. Companies will need to try both the JLCA and J# on specific applications and compare the results.

Sun APIs and a non-Microsoft tool. This scenario is largely the same as migrating from Visual J++ to .NET. The only substantial difference is that developers will need to adopt a Microsoft tool. Any project settings or compiler options will be lost in the conversion and developers will need to learn a new development environment. Given the very high degree of customization that is possible with Visual Studio .NET, and the wide variety of third-party support, changing development environments is unlikely to pose a major obstacle to adopting .NET.

Finally, there is the option to not adopt .NET at all and stay with Sun's Java APIs on a competing Java platform. Several companies, including BEA, IBM, and Sun have announced Java-based products for creating Web services, and those products may be the better choice for customers who have extremely large investments in Java and in APIs that aren’t supported by either J# or the JLCA.

Production, Enterprise Releases to Follow

The JLCA will be released in two versions: a Standard Edition (now in beta) is a free add-on to Visual Studio .NET and a separately priced Enterprise Edition will be available for purchase from Artinsoft. This software development and consulting company based in Costa Rica is developing both editions of the JLCA as well as the Visual Basic 6-to-VB.NET upgrade tool that is included in VS.NET. The Enterprise Edition will translate server-side components such as Enterprise Java Beans (EJBs) to C#.

The final version of JLCA Standard Edition is expected to be released in mid-2002. The Enterprise Edition will be in beta in the second half of 2002 and released in 2003.

Resources

The beta of the JLCA Standard Edition can be downloaded from the Visual Studio page on MSDN at msdn.microsoft.com/vstudio/downloads/jca/default.asp.

For background on the .NET platform and .NET's advantages for Web services, see the Feb. 2002 Research Report, "The .NET Development Platform."

Information on Visual J# is available on MSDN at msdn.microsoft.com/visualj/.