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
