Many organizations have a mix of .NET and Java code today. Unfortunately, it appears that the two language platforms are incompatible, causing considerable woe for users and developers alike; or are they? The purpose of this article is to demonstrate that you can interact with Java in your .NET applications at many levels and migrate Java solutions as needed. Although the ultimate level of interaction may be to translate your Java code into a .NET equivalent, you can also create a bridge between your application and the Java code you need to use. To see for yourself that many companies have provided the required bridge between their applications, check out the case studies on the Microsoft NXT site.
Defining the Issues
The most important issue to consider is how best to protect your code investment, while maximizing your ability to create a unified solution. One of the most common methods is to use Web services because using this technique means you don't have to perform any code translation. In some cases, interoperability means providing a bridge between your new .NET development and any existing Java code using products such as JNBridge (described in detail later in the article) or J-Integra Expresso. In other cases, you can move your Java code right into the .NET environment by translating it using conversion solutions such as the Java Language Conversion Assistant (JLCA). A standard version of JLCA comes with Visual Studio .NET (learn more here), but you can also purchase the JLCA Companion from ArtinSoft to improve the conversion process. The method you choose depends on the application you need to support and the environment in which you need to support it. Often, you'll need to apply several methods in order to obtain the results you desire.
Timing is another essential element in moving your application from Java to .NET. Few organizations can afford to shut everything down, recreate their applications, and then start up again. A more logical approach is to transition existing code as needed and to build new application modules using .NET. Whether you transition the Java code or translate it depends on the code complexity. For example, business logic code usually transfers with few, if any, problems as long as you can create the proper correlation between Java and .NET calls. The
J+N Java Interoperability site presents business scenarios, provides interoperability guidelines, tells about partner solutions, and describes partner services to help you make good organizational decisions.
It's also important to consider the skill set of the developers on your team. In some cases, a bridging solution might work best when you don't have developers who understand both Java and .NET. However, when you have developers on your team with the right skill set, you'll find that you can convert business logic code quickly and easily. As you define the issues for your organization, you'll want to make use of Microsoft resources in defining which solutions work best for you. You can find some basic ideas at the
Microsoft Migration Resources site. Make sure you also review the materials on the
Microsoft .NET and Java/J2EE Interoperability site. Microsoft even provides a free workshop on the
Java to .NET Framework Migration Workshop: Free Online Training site.
Choosing the Right Solution
As stated above, for many organizations, Web services are the right solution because you can provide interoperability with just about any platform without performing any code conversion. All you need to do is make the object methods and properties accessible using a technology such as Simple Object Access Protocol (SOAP) or REpresentational State Transfer (REST). Web services appear in many places today and you can find many public Web services to use as a guideline for creating your own Web service. The basic problems with Web services are security (the data transfer is in text) and performance (bulky XML transfers can create a performance hit). However, Web services are also extremely flexible and easy to understand. You can learn more about Web services a here.
Bridging makes it easy to access your Java code today and move it slowly to Windows® as you build new modules. You can use the bridge to interoperate between your current .NET and Java code, and, as you migrate Java modules to .NET and the platform boundary moves, you can move the bridge to cover the shifting platform boundary. With bridges, the Java code still runs in a JVM (Java Virtual Machine) and the .NET code still runs in a CLR (Common Language Runtime); the bridge manages the communications and makes it transparent to the developer. One such bridge, JNBridge, provides three different ways for the .NET and Java sides to communicate. See the "Considering the Bridging Solution" section of the article for more information on this solution.
Another solution is to translate your Java code into a .NET language and recompile it. The JLCA and JLCA Companion products by ArtinSoft map Java calls to those used by .NET. This mapping lets JLCA convert the Java code into something that works with .NET. See the "Considering Code Conversion" section of the article for more information on this solution. If you're working with Java Server Pages (JSP), then you'll want to check out Microsoft's JSP to ASP.NET Migration Guide.
In most cases, code conversion works better with business applications because converting graphics, such as those used by Swing, are difficult at best (see "Swing: a Quick Tutorial for AWT Programmers" for details on Swing and other Java technologies).
If you find that you have a hard time making a choice on which strategy to employ, Microsoft provides a number of best practices articles on Microsoft Developer Network (MSDN). You can also get free training on MSDN. Although this article does cover a number of solutions, you can find many other cross-platform vendors on the NXT site.