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.