Migrating from Java to .NET is not easy, and you might be better off with your exisiting application. Here are five reasons for sticking with Java.

The .NET Framework has been touted as the next big thing for the distributed computing community. Redesigned from the bottom up, Microsoft's newest offering has made marked progress in areas such as XML integration, error handling, component processing, and reusable frameworks. The promise for Web development is clear: faster development, less custom coding, and increased stability.

But what if your current application is currently a Java EJB implementation? Is it worth the cost and effort to migrate to Microsoft's new platform? While the benefits of .NET over Java EJB certainly will be debated for years to come, the difficulties involved with such a platform port are a little more predictable. Even assuming a compelling technical or business reason driving the requirement, here are five good reasons not to migrate your Java or J2EE applications to .NET.

1. CLR does not support Java
The first stumbling block on the road to .NET is its set of supported languages. The .NET Framework relies on a Common Language Runtime (CLR) that promises compatibility with multiple languages, but this compatibility is limited currently to C#, C++, VB, and (soon to come) J#. Not surprisingly, Java is not a supported language in the CLR.

It's possible to migrate the Java application tier to .NET without rewriting the application code in a CLR-supported language by using a Java COM bridge or Web services. Java COM, however, relies on third-party applications to create COM DLLs directly from pure Java code. Difficulties in debugging the resultant binary, as well as increased complexity in the environment, illuminates why such heterogeneous application development should be approached with caution, or avoided completely.

An alternative strategy is to port your Java code to C# code. In theory, you can translate Java code directly into C# (and J#) code through automated applications. For example, ArtinSoft's Java Language Conversion Assistant Enterprise Edition (JLCA EE) promises up to 99 percent automatic conversion from Java to C#. However, such products have yet to prove themselves in the marketplace, and experience argues against believing in automatic code conversions. Whether through an automated processor or done manually, a language port will undoubtedly require associated architectural changes. Depending on the implementation specifics of your application, significant refactoring may be required when rewriting a Java application to VB, C++, C#, or J#.

2. IIS does not support JSP
As if an application language port from Java to C# is not daunting enough, .NET will also require a presentation language port. JSP is not supported by IIS. Moving from JSP to ASP.NET is a significant undertaking and will demand a complete rewrite of the presentation layer. Additionally, major architectural models, such as code reuse through tag libraries, are not supported in ASP.NET. Tag libraries must be converted to server controls or server side includes (ssi). Interestingly, Java classes written to support tag libraries conceptually match .NET's code-behind classes. Significant work, however, will be required for the actual conversion.

3. Server controls require redesigns
As mentioned, new architectural requirements will undoubtedly surface during a language rewrite of your code base for .NET. This will become immediately evident if the implementation of .NET server controls is planned. ASP.NET server controls are one of the biggest advantages offered by .NET. By utilising prebuilt server components, developers can reduce repetitive coding and easily access functionality through objects. Taking advantage of server controls during a migration to .NET will most likely entail removing custom presentation, application, and database code and replacing it with a server control and required database logic.

When upgrading from an existing Microsoft application, this code extraction will not be difficult, especially if good coding practices have resulted in cleanly partitioned and well-organised code. However, when moving from a Java EJB application, server controls require deep vertical migration and may simultaneously impact the data, application, and presentation tiers of the application. Not only will the stored procedures, Java objects, and JSP files require porting to Microsoft-supported standards, they also will have to be modified to support the Server Control.

For example, the DataGrid object provides complex table functionality to display a set of data records. Row and column selection, header styles, and paging functionality are just a few of the properties available for customisation. The DataGrid object is more functional and maintainable than any custom or proprietary code base is likely to be. But to take advantage of this control during a port from a Java application (assuming you're moving an Oracle data tier to SQL Server), it would require:

• Rewriting P/L SQL to Transact SQL while formatting the queries to support the DataGrid.
• Rewriting the Java application code into a .NET-supported language to invoke the SQL or stored procedures and to support the event model of the DataGrid.
• Rewriting the JSP templates to ASP.NET while removing the code supporting the existing, custom data presentation objects.

4. No support for Container Managed Persistence
Assuming that the existing Java application is supported by a non-SQL Server database, migrating the application will most likely require either porting the database over to SQL Server or integrating the proper drivers to allow your .NET application to persist data through a non-SQL Server database. In either case, you'll need to rewrite your JDBC connection classes to ADO.NET and migrate your Java ResultSets to ADO.NET DataSets. This task in itself is not overly difficult. DataSets and ResultSets are similar mechanisms and beyond implementation specifics should not require significant rearchitecture.

Migration difficulties will start to surface when the dev team begins porting object persistence from Java to .NET. .NET has no support for Container Managed Persistence (CMP) and no similar mechanism. If your application relies on CMP for object persistence, you'll be forced to rewrite these object classes with the embedded logic for data retrieval and loading.

5. Different session handling implementation
The EJB standard does not specify the handling of session data, so EJB session-handling implementation becomes completely application server specific. Since differences in session-handling implementations can have a profound impact on performance, scalability, and network design, you must understand the implementation details of your application's session-handling mechanisms.

In .NET, Microsoft introduces a distributed session model that makes session data available over multiple application servers in a Web farm by using Microsoft SQL Server to store the application state. Since .NET relies on embedded functionality within SQL Server for sessioning, heterogeneous applications using Oracle or other non-SQL Server databases will be required to implement a SQL Server instance solely for distributed sessions. Additionally, since large amounts of session data will reduce overall system performance, prudent use of session storage is a necessity.

Uphill battle to parity
The .NET Framework represents Microsoft's latest effort to function in the world of highly available, enterprise-level applications. Many features long absent from previous versions of IIS, Visual Studio, VB, and SQL Server are now available on the new platform. Microsoft developers and users can start to feel parity with other industry competitors in realms of scalability, extendibility, security, and performance.

Industry hype aside, the key point is that .NET represents only parity with EJB solution providersââ,¬"there is no overriding indicator that the .NET platform is superior to WebSphere, WebLogic, or any other EJB application server. For existing IIS/ASP solutions, the benefits to migration are clear. For new initiatives, depending on staff skills and organisation orientation, .NET may be the framework of choice. But for existing Java EJB applications, unless you want to fight an uphill battle to parity, leave them right where they are.

Copyright © 2009 CBS Interactive, a CBS Company. All Rights Reserved.
ZDNET is a registered service mark of CBS Interactive. ZDNET Logo is a service mark of CBS Interactive.