Migrating Java* Applications to C# on the .NET* Platform

Published: 01/25/2011, Last Updated: 01/25/2011

by Allan McNaughton


The launch of Microsoft's .NET* initiative has piqued the curiosity of Java* programmers. The Java platform – which has made inroads in the market for server applications – now has a worthy competitor that builds on the promise Java offered to simplify the life of enterprise developers. The .NET* platform offers an extensive array of services that, when combined with industry leading development tools, can lower the total cost of developing and deploying distributed multi-tier applications.

Significant Similarities

At the forefront of the .NET strategy for attracting enterprise developers is the C# programming language. The C# language will be immediately familiar to Java developers as they share the same design principles and language fundamentals. "The similarities are so great", says Larry O'Brien, noted C# expert and author of the book Thinking in C#, "that an experienced Java developer should be able to understand C# code without extensive training."

Much of the similarity between Java and C# comes from shared roots in C++ and adherence to the principles of object orientation. Both languages lack the concept of a global function or data item–everything must belong to a class that is allocated on a garbage collected heap. Java and C# also share similar mechanisms for exception handling although C# does not have checked exceptions. The complexity of multiple inheritance in C++ is replaced with the simplicity of single inheritance. The age-old problem of namespace collisions is solved by the introduction of a hierarchical naming scheme which approximates Java packages functionality.

At the platform level .NET is based on an execution engine, the Common Language Runtime (CLR), which is functionally similar to a Java Virtual Machine (JVM). The CLR differs from the JVM in that it can host more than one language; it currently supports Visual C#.NET*, Visual Basic.NET*, Visual J#.NET*, and Visual C++.NET*. Another similarity between platforms is the use of a Just-In-Time (JIT) compiler. The primary difference between JIT implementations is that the Java JIT compiles code on the fly as classes are executed while the .NET JIT compiles entire assemblies when they are first loaded.

Subtle Differences

At the nuts-and-bolts level of language details, C# differs primarily from Java in that it has a more C++ like syntax and supports additional programming constructs. One of the common complaints voiced by former C++ turned Java programmers was the lack of a pre-processor – C# brings this useful feature back to life. The C# language also supports additional C++ like features including structures, enumerated types, casts, and operator overloading. Mundane programming tasks are simplified via support for properties, delegates, indexers, and a very useful foreach statement. The most significant difference encountered by Java developers is all C# methods are non-virtual by default – as compared to Java's default virtual methods.

A major difference between the two languages is that C# allows developers direct access to pointers while Java does no t. Java's developers restricted the languages users from direct memory access both in order to eliminate programmer inspired error through improper memory management and in order to ensure maximum portability of Java applications. In order to affect these goals, the designers mandated that all memory access be through object references rather than direct pointer arithmetic. The downside to this arrangement is that users were forced to trade speed for safety and good programmers were unfairly penalized. C# hews to a middle road between the freewheeling data model of C and C++ and the rigidity of Java. In C#, the default environment is the same as Java, memory is accessed through reference rather than direct pointers. C#, however allows developers to declare a specified area of code as "UNSAFE" and have direct access to pointers and disk memory. This added flexibility allows for more agile programming and greater options available to the programmer.

The .NET platform is, of course, intended for deployment on the Microsoft Windows* operating system. The need to interoperate with legacy (pre .NET) code has resulted in C# supporting a host of interoperability features. Calling out to native functions in Win32 DLLs is done via the Platform Invoke service – with minimal effort (only two additional lines of code are required). Interoperability with COM objects and ActiveX controls is also a trivial process as Microsoft Visual Studio.NET* provides full support for the automatic creation of .NET compliant type metadata from COM type libraries.

Things start to get really interesting when you look at more than just the C# language and the .NET runtime engine. These components, although essential to the .NET platform, are mere supporting mechanisms for the vast .NET Framework class library and services contained within. The real value in the .NET platform is not just the user friendly C# programming language, but how simple it is to build powerful enterprise applications using the provided tools and class libraries.

The .NET Framework class library consists of multiple layers of increasing abstraction. At the lowest level are the .NET base classes that support system services such as threading, strings, collections, networking, and input/output – these are very similar to the base classes defined in the Java 2 Platform Standard Edition. This makes the conversion process simpler than it would be otherwise.

The data layer in .NET consists of classes to support ADO.NET, SQL, and XML. An interesting point of divergence is ADO.NET's disconnected data model. Unlike JDBC–which requires many back and forth trips to the database–ADO.NET can query the database, bring back a result set, and work on it in the middle tier. Scalability can be significantly increased as the disconnected model reduces demand on database servers.

Developers of Java GUI applications will find that .NET provides a rich set of features in Windows Forms. These features offer an easy migration path for Swing and Java/AWT developers to move graphical applications to the native Windows interface. JSP programmers will find much to like when migrating code to ASP.NET (also known as Web Forms). This improved version of ASP now supports development in C# in addition to existing Visual Basic and Jscript. ASP.NET server controls give developers the flexibility to extend tag funct ionality-perfect for migration of JSP tag libraries.

A key differentiator of the .NET platform is integrated support for Web services. As much of .NET is built using XML technologies, the platform offers full support for SOAP, WSDL, and UDDI. With tools such as Microsoft Visual Studio.NET, it is a trivial matter to expose application functionality as a Web service. Although Java does offer all the technologies necessary to build Web services, it is not at the crux of the J2EE platform – this shows in the level of development effort required.

Migration Strategies

One approach for migrating applications to .NET is to rewrite existing functionality in C#. A total rewrite may be viable if the existing Java application has architectural deficiencies that require a major overhaul to rectify. Development managers should allocate sufficient time for team members to learn the extensive array of .NET API calls, switch development environments, and implement new deployment procedures. "Although the learning process takes time", states O'Brien, "experience has shown development using the .NET environment is more productive than J2EE".

A safer strategy would be to migrate parts of the application to .NET and leave the remaining components running in Java. There are multiple ways to accomplish this goal, and the desired approach depends on the level of integration desired. A simple approach is expose key application interfaces using Web services. The .NET components can make SOAP calls to the Web services and incorporate the results. This solution may be viable if, initially, the business logic stayed on the Java server while presentation layer functions are moved over to ASP.NET. Over time the business logic components could be rewritten in C# and deployed on the .NET server.

Interoperability between C# and Java code can also be achieved by using wrapper solutions. Wrappers, otherwise known as software bridges, allow for transitions between incompatible software environments. This approach has been used for many years to solve compatibility problems – from thunking between Windows and DOS* to connecting mainframes with Web applications. A third party wrapper product, such as JNBridge*, allows .NET classes to call Java classes if as they were native .NET code.

Java applications already deployed on Visual J#, Microsoft's version of Java based on JDK1.1.4, will experience seamless interoperability as both the Java and C# components execute in the same .NET Common Language Runtime. Visual J# is provided by Microsoft primarily as a convenient way for Visual J++ 6.0 developers to adopt the .NET platform. Developers of J2EE applications will not find Visual J# suitable due to the many incompatible changes that have occurred between JDK1.1.4 and the most recent JDK, version 1.3.

Microsoft is working to smooth the migration path with the introduction of its Java Language Conversion Assistant* (JCLA) tool. This tool is central to its JUMP to .NET strategy (Java User Migration Path to Microsoft .NET) and is designed to convert Visual J++ 6.0 projects directly into C# with minimal developer intervention. The tool also remaps Java API calls into functionally equivalent .NET versions. Although useful for Visual J++ 6.0 users, JCLA is not suitable for J2EE app lications as it is limited to JDK1.1.4 compliant applications.

ArtinSoft, developers of the Microsoft JCLA tool, is building a conversion tool tailored to the requirements of enterprise Java applications. This tool supports the latest JDK and an ever-increasing swath of the J2EE API. "Users of the Microsoft JCLA tool are experiencing conversion rates of 90%", says Federico Zoufaly, Executive VP of ArtinSoft. "The J2EE focused migration tool – which is in the final development stages – aims to achieve a conversion rate of at least 80%," he added.

Decisions, Decisions

The decision to move development efforts from Java to C# and the .NET platform should be made only after thoughtful deliberation. "The choice to switch platforms cannot be reduced purely to a technical level", says Larry O'Brien. One must consider the expected life span of the target application as it may make sense to target .NET development efforts towards a next generation product that supercedes the existing Java version. Another key factor is the skill set of the development team. Says O'Brien "Although .NET is-in many ways-a more productive environment than J2EE, managers should inventory the skills of their team to ensure a good cultural and technical fit."

Once the decision is made to start a pilot C# project (or the more ambitious goal of migrating an existing Java application to C#), Java programmers will find the .NET platform offers a rich array of tools and services that facilitate the rapid construction of enterprise applications. Regardless of the chosen .NET adoption approach – total migration, incremental rewrite, or new project development – Microsoft and third party vendors can provide the tools and expertise to get the job done quickly.

About the Author

Allan McNaughton is the Principal Analyst at Technical Insight, LLC*, a firm specializing in the development of high-technology white papers. He can be reached at allan@technical-insight.com.

Related Resources


Other Resources


Product and Performance Information


Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.

Notice revision #20110804