Migration from Java to Microsoft.NET

Introduction

Java has been around for almost 15 years now. It was a complete paradigm shift and Sun Microsystems' (Now Oracle-Sun) initiative to move away from a conventional platform based programming model to a Runtime based programming model which would allow us to run the same application on different platforms without any code change.

.NET initiative was Microsoft's strategy to confer competition to Sun's J2EE or more famously the Java Technology. Microsoft.NET has been in place for almost 7 years.

This paper is not intended to depict the fundamentals of these two technologies. This paper is to throw light on the ways and means of porting a Java based application to .NET.

In theory, both the technologies are the fundamentally similar. Both are architected in a similar way and both serve the same purpose. There are just two fundamental differences though, between these two competing technologies:

• Runtime for Java (called as JVM or Java Virtual Machine) is available for all the platforms such as Windows, Linux, Solaris, Mac OS X, Unix etc. On the contrary, Runtime for .NET (called as CLR or Common Language Runtime) is available (as of now) only for Windows. Although there are few open source initiatives to build a runtime for the other platforms too. One of such initiative is called “Mono Project” (http://mono-project.com/Main_Page).



• The language used for developing applications in Java Technology is confined to only one, i.e. JAVA language, whereas there are quite a few languages that can be used to develop a .NET based applications, such as VB, C#, C++, J#, Perl.NET etc.

There are more differences between the two technologies, but they are not very significant with respect to this article.

Need for Migration from Java to .NET

The most common need for migrating a Java Application to .NET (or even vice-versa) is Platform consolidation. Companies & ISVs are constantly trying to reduce the cost of maintaining their products or software, by keeping the skill sets required to maintain all the products to be common so that they take advantage of a smaller team specialising in “one” technology. And since Java &.NET are architecturally the same, the migration from one another is quite straight-forward.

This article will focus on converting Java applications to .NET.

Types of Migration

There are two types of migration available for converting Java applications to .Net:

• Upgrade to Visual J#.NET

J# is one of the languages that can be used to develop applications targeting to the .NET CLR. The syntax for J# is same as Java. The reason for existence of this language is to provide a faster migration path for Java developers to learn and start writing software for .NET.

Upgrading Java applications to J# is the fastest and easiest way to port Java applications to .Net. Java developers are instantly productive on J#.Net because the syntax and set of class libraries are similar to Java.

Visual J# .NET consists of a Java language compiler and the required class libraries designed to provide the functionality equivalent to most of the JDK level 1.1.4 packages. The classes in the java.util package support functionality equivalent to JDK level 1.2 class libraries and classes in the Microsoft Supplemental UI Library for Visual J# provide much of the functionality as described in the Java 2 JFC Swing specifications. It also consists of a tool to upgrade compiled Java byte code to MSIL—useful for upgrading libraries to a form that can be used from .NET Framework-based applications. In addition, like other .NET-compliant languages, J# too has full access to the .NET Framework, and includes designers for building Windows Forms and ASP.NET Web Forms based applications.

In many cases, essentially where business logic preservation is a goal, upgrading to Visual J# .NET is the easiest and quickest way to move Java applications to the .NET. With a familiar syntax and set of class libraries, developers can leverage their existing knowledge of Java, and become productive on the .NET immediately. The upgrade is very quick, and developers can begin to add features with the .NET Framework and Microsoft extensions to the Java language.

• Converting Java code to C# using a Tool

Microsoft developed a tool called the Java Language Conversion Assistant that can be used to convert Java applications to Visual C# .NET. Code that calls Java APIs is converted to comparable C# code that uses the .NET Framework. Because of the complexity of the conversion, not all Java APIs are converted. The Java Language Conversion Assistant converts about 90 percent of JDK and J2EE version 1.3 calls, EJB, JAAS, JCE, JMS, JNDI, RMI, and JAXP, and emits issues in code for the other 10 percent. Each issue is linked to a topic with guidelines for what modifications are to be made and code needs to be written manually.

Although converting to C# is generally more labour-intensive task than upgrading the code to Visual J# .NET, it offers more flexibility to the software because the application is converted to use the native .NET Framework APIs. Hence the converted code will immediately take advantage of all the features of the .NET Framework.

The next section provides a like-to-like mapping of the Class library, components and its implementation in Java & .NET

Migration Mappings

• Like to Like Components

Java Technology	Upgrade to Visual J# .NET	Convert to C#
Java language	Java language	C# Language
Applet	Supported via J# Browser Controls	Windows Forms control
JavaBean	JavaBean	System.ComponentModel System.Windows.Forms.UserControl
ActiveX control	Supported via J# Browser Controls	ActiveX control
AWT frame	AWT frame	Windows Form
WFC form	WFC form	Windows Form
Compiled library	Compiled library	Not converted
Resource file	ResX file	ResX file
CORBA	Not Converted	.NET Remoting System.Runtime.Remoting;
RMI and RMI IIOP	Not Converted	System.Remoting System.Security System.MarshalByRefObject
DHTML	Not Converted	System.Web.UI.WebControls
Enterprise Java Bean	Not Converted	System.EnterpriseServices
Java Authentication and Authorization Service	Not Converted	System.Security
JavaBeans Activation Framework	Not Converted	System.Windows.Forms.DataObject
Java Mail	Not Converted	System.Web.Mail
Java API for XML Processing	Not Converted	System.Xml
Java Cryptography Extension	Not Converted	System.Security.Cryptography
Java Database Connectivity	Not Converted	System.Data.OleDB
Java Messaging Service	Not Converted	System.Messaging
Java Naming and Directory Interface	Not Converted	System.DirectoryServices
Java Server Pages	Not Converted	ASP.NET
Java Transaction API	Not Converted	System.EnterpriseServices
Microsoft Transaction Server	Not Converted	C# Class (Serviceed Component)

• Individual Packages vs. Assemblies

Package	Upgrade to Visual J# .NET	Convert to C#
com.ms.awt java.awt	Java.awt	System.Windows.Forms
com.ms.com	com.ms.com	System.Runtime.InteropServices
com.ms.dll	com.ms.dll	System.Runtime.InteropServices System.ComponentModel
com.ms.dxmedia	Not Upgraded	DirectAnimation
com.ms.fx	Not Upgraded	System.Windows.Forms
com.ms.io	com.ms.vjsharp.io	System.IO
com.ms.lang	com.ms.lang	System Microsoft.Win32.RegistryKey
com.ms.object	com.ms.vjsharp.object	System
com.ms.ui	Not Upgraded	System.Windows.Forms
com.ms.util	com.ms.util	System System.Collections System.Diagnostics
com.ms.wfc.app	com.ms.wfc.app	System.Windows.Forms System.Globalization.CultureInfo Microsoft.Win32 System.Environment.SpecialFolder System.Threading System.DateTime
com.ms.wfc.core	com.ms.wfc.core	System System.ComponentModel System.Windows.Forms.Design System.ComponentModel.Design System.Resources
com.ms.wfc.data	com.ms.wfc.data	ADODB System.Runtime.InteropServices RDS System.Globalization System System.ComponentModel MSDASC System.Resources
com.ms.wfc.data.adodb	com.ms.wfc.data.adodb	ADODB
com.ms.wfc.data.ui	com.ms.wfc.data.ui	System.Windows.Forms System.Data System
com.ms.wfc.io	com.ms.wfc.io	System.IO System.Globalization
com.ms.wfc.ole32	com.ms.wfc.ole32
com.ms.wfc.ui	com.ms.wfc.ui	System.Windows.Forms
com.ms.wfc.util	com.ms.wfc.util	System System.Diagnostics System.Collections System.Runtime.InteropServices System.Resources System.Globalization
com.ms.wfc.win32 com.ms.win32	com.ms.wfc.win32 com.ms.win32	Converted to PInvoke calls
java.io	Java.io	System.IO
java.lang	Java.lang	System System.Threading
java.lang.reflect	Java.lang.reflect	System.Reflection System
java.math	Java.math	System.Decimal
java.net	Java.net	System.Net System System.IO
java.security	Java.security	Not Converted
java.sql	Java.sql	System.Data.OleDb System.DateTime
java.text	Java.text	System System.Globalization System.Resources
java.text.resources	Java.text.resources	System.Resources
java.util	Java.util	System System.Collections System.Globalization System.Resources System.Configuration
javax.swing	javax.swing	System.Windows.Forms

Retirement of Visual J# & JLCA tool

Microsoft has retired the Visual J# product and Java Language Conversion Assistant tool starting Visual Studio 2008. The J# language and JLCA tool will not be available in future versions of Visual Studio. To preserve existing customer investments in J#, Microsoft will continue to support the J# and JLCA technology that shipped with Visual Studio 2005 through to 2015.

Way forward

As mentioned in the Section 5, although the two (automated) methods of converting Java code to .NET are retired by Microsoft, they are still available to be used to convert 90% of the conversion to make things easier for complete conversion.

The decision to automate the code conversion or to rewrite / re-architect the product is based on 1 governing principle – “How well architected is the original Java System”. If the Java system is very well architected and does not need any architectural change, then using the tool / converting it to J# makes more sense since the framework for java and the Framework for .NET is more or less similar and most of the features have a like-to-like mapping with each other.

If the process of migrating a Java application to .NET is initiated due to an existing poor design of the product, then the best option is to completely re-architect & re-design the product from ground up taking into account the best practices of Microsoft.NET. In this case, use of automated migration may not provide the best solution.

References

http://msdn.microsoft.com/en-us/library/ms973842.aspx