One of the most significant features of .NET is support for cross-language development. The platform allows a class written in one .NET language to be called by, or inherited by, a class written in another .NET language. For various reasons, Java* is not part of .NET's cross-language framework. However, there are numerous reasons why developers integrate Java and .NET code, some of which are technology-driven, and some of which are business-driven.
- A development organization may want to reuse existing Java libraries in an ongoing .NET development effort. The Java libraries may have been obtained from third parties and only available in binary form, making migration to a .NET language impractical.
- Technical requirements may dictate that part of a project remain portable and cross-platform compatible. This generally means implementation in Java, while other portions are targeted to the .NET platform.
- The .NET framework may provide functionality unavailable under Java. In this case, developers enhance a Java class with .NET functionality by creating a new .NET class that inherits from the Java class.
- A heterogeneously skilled development team may have some developers with Java skills and some developers with .NET skills.
- The team's goal may be to produce Java and .NET versions of a product from a common code base.
- There may be a business decision to migrate to .NET servers while retaining (or even continuing development of) "legacy" Java code.
Depending on the reason for doing the integration, a developer might employ a service-level integration, in which Java capabilities are exposed to .NET as a set of Web services, or a class-level integration, in which Java classes participate in the cross-language development framework in the same way as other .NET languages. If a class-level integration is appropriate, several approaches are available, including porting an entire platform to .NET or Java, compiling Java source to .NET, cross-compiling between Java and .NET, or using a bridge between the Java and .NET platforms.
While each platform has its advantages and disadvantages, a bridging approach employing JNBridgePro and Intel® microprocessor-based systems provides the best combination of advantages, including portability, flexibility, the ability to conformance to standards, and smooth interoperability.
Java-.NET Interoperability Through Web Services
While Web services have received a great deal of attention as an integration strategy, there are a number of reasons why they may be inappropriate for implementing Java-.NET interoperability.
One is that the Web service models provided by .NET and Java-based platforms are not entirely compatible. .NET's Web service model is document-based, while Java-based platforms employ a remote procedure call (RPC) based model.
Web services may also be inappropriate when the interaction between client and server is frequent and fine-grained, as in the case where a method in a .NET class repeatedly and frequently calls a method in a Java class. In these cases, the overhead of Web services may overwhelm the time spent executing the Java method itself.
We b services also do not support callbacks or method overrides, and they do not explicitly support object orientation of the maintenance of an inheritance hierarchy. In other words, while Web services are useful for integration tasks between coarse-grained services and applications. For typical development-stage tasks involving fine-grained interactions between objects, a different model is necessary.
Class-Level Java-.NET Interoperability
A number of approaches to Java-.NET interoperability do not depend on the Web services model, including porting the entire .NET platform to Java (or porting the entire Java platform to .NET), compiling Java source code directly to Microsoft Intermediate Language (MSIL), or cross-compiling Java code to .NET (or vice versa), either at the source or binary level. Each of these solutions has one or more of the following disadvantages:
- The user may be locked into a single version of Java or .NET, causing interoperability to fail as the Java or .NET platforms evolve.
- The Java code may run only on Windows* and will lose its cross-platform capabilities.
- There may be no guarantees that the Java code's behavior conforms to Java standards if it is not running on a Java virtual machine (JVM).
- Source code, which is often difficult to access, may be necessary.
- Interoperability with compiled Java libraries may not be possible.
Bridging solutions offer a more flexible approach to Java-.NET interoperability. When bridging is used, Java code is not converted to .NET or vice versa. .NET classes run on a Common Language Runtime (CLR), Java classes run on a JVM, and the bridging solution transparently manages the communications between them.
To expose classes from one platform to classes on the other, proxy classes are automatically created that offer access to the underlying real class. Thus, to allow calls from .NET methods to Java methods, proxies are created on the .NET platform that mimic the interfaces of the corresponding Java classes.
A .NET class can inherit via Java class's proxy, and vice versa. In order to preserve the cross-platform properties of the Java code, the bridging solution can disallow the generation of Java proxies for underlying .NET classes. If the Java classes cannot call or inherit from the .NET classes, then their portability is preserved.
Bridging solutions have a number of advantages over other interoperability approaches, including that these solutions evolve as platforms evolve. Future versions of Java and .NET will work with the bridging solution as long as they remain backward compatible. As new versions of Java and .NET are introduced, they can be incorporated without the necessity of updating the bridging solution.
An additional advantage of bridging solutions is that, since the Java runs on a JVM, it is not necessary to have source code. The solution will work when only Java binary is available.
Bridging solutions are also guaranteed to conform to standards, since the actual runtime environment is a CLR or a JVM, and as long as the runtime environments and compilers conform to standards (likely, if Sun or Microsoft reference compilers are used), the resulting code will exhibit conformant behavior.
JNBridgePro is a Java-.NET interoperability tool that enables new or existing Java code to participate in the cross-language development capabilities of .NET and retain Java's cross-platform capabilities and conformance to standards. JNBridgePro allows classes written in languages like C#, C++, and Visual Basic to seamlessly and transparently access Java classes as though Java were itself a .NET language.
JNBridge Pro also supports full implementation inheritance through a number or unique features:
- Controlled access to non-public Java classes and members, including default-access classes and protected members. Access to these classes allows inheritance from the .NET proxy to be the same as inheritance from the actual Java object.
- The ability to override Java methods in inheriting .NET classes, and having the Java side recognize those overrides.
A system using JNBridgePro consists of Java and .NET. (Figure 1.) On the .NET side are the classes of the driving the .NET application, the assembly consisting of the generated proxies, and a runtime component containing a set of core proxies and classes to manage Java-.NET communication and references to Java objects.
On the Java side are the Java classes, either as individual class files or Java Archive (JAR) files, and a Java runtime component that manages communication, method dispatch, and object references on the Java side.
The Java side can run inside a stand-alone JVM or in any application server with a J2EE servlet container. The .NET side can be a stand-alone application, an ASP.NET Web application, or a Web service. JNBridgePro uses Hyper Text Transfer Protocol (HTTP)/ Simple Object Access Protocol (SOAP) or a fast binary protocol based on .NET remoting. No change to the code is required to switch between communication protocols, only changes to configuration files.
In addition to the runtime components, JNBridgePro contains a proxy generation tool, JNBProxy. This tool creates the .NET proxies for the Java classes whose functionality and interfaces are to be exposed to .NET.
Figure 1. JNBridgePro Architecture
Advantages of the Intel-based Platform for Java-.NET Interoperability
The performance of software in general, and a bridging solution such as JNBridgePro in particular, depends in large part on the performance of the underlying hardware platform.
The main factors in measuring the overhead of the JNBridgePro interoperability solution are the time spent in conveying a method call and return from the .NET platform to the Java platform and back, and the time spent passing parameters and return values between the Java and .NET platforms. The JNBridgePro proxy mechanism, the runtime engines on both the Java and .NET sides, and the communication mechanisms connecting the runtimes all influence this overhead.
Underlying these issues are the operating system and hardware platforms on which the .NET and Java run times reside, and the ways in which the runtimes are optimized for the underlying operating systems and hardware platforms.
Intel is involved with optimizing all of the different pieces of the puzzle. In fact, much data is available on how Intel-based platforms provide a cost-effective and high-performance Java solutions. Several JVMs, including those offered by IBM and BEA, have been optimized for performance on the Intel® Architecture (IA) and provide excellent performance. Microsoft's operating system functionality and the .NET-based runtime are optimized on IA.
These performance improvements take advantage of features of the Intel processor-based architecture, particularly the 32-bit Intel® Xeon® and the Intel® Pentium 4 processor families and the 64-bit Intel® Itanium® and Intel® Itanium® 2 processor families.
The IA-32 architectural features that help to improve the performance include SSE2, Rapid Execution Engine, Instruction Trace Cache, Intel NetBurst® microarchitecture,Hyper-Threading Technology, large cache size, and a faster system bus. (Please note that this paper focuses on IA-32 only.)
In addition to the hardware architectural features, Intel has excellent tools to improve the performance of the applications, including compilers, performance analyzers and libraries, and threading tools.
JNBridgePro Performance on the Intel-based Platform
To measure the performance of JNBridgePro's tightly coupled Java and .NET interoperability solution and the ways in which it is improved by use of an Intel-based platform, a simple test scenario was created in which a C# method calls a Java method. Inter-platform communication entails passing parameters to the Java method and receiving values on return. Array and string data types of varying sizes are passed as parameters and return values.
We measure the overhead due to method calls and returns across the Java-.NET boundary, marshalling and un-marshalling parameters and return values and passing them across the Java-.NET communication mechanism. TCP/IP is the underlying communication protocol and binary serialization is used. (See Figure-2 for a description of the overall experimental setup.)
Figure 2: Experiment setup for a tightly coupled application using JNBridge
- Create C# class
- Create Java class
- Create proxy from the Java classes
- Compile the C# class and build application using proxy
- Profile the C# application using DevPartner* ( DevPartner is a profiling tool from Compuware Corporation*)
- Extract the total time from the profiled data.
- Extract the time spent on interoperability overhead, including call/return and parameter and return value passing.
For simplicity, only one system was used for the experimental scenario. The components, Java, .NET and JNBridgePro mechanism, all sat on a single machine. The purpose of this simple test was to understand the performance characteristics of JNBridgePro on Intel-based platforms. The performance of the JNBridgePro's tightly coupled interoperability framework-based application improves on more powerful Intel platforms.
Table 1: Total time (ms) to execute the test application
The efficiency of the JNBridgePro solution is most accurately determined by measuring the amount of time spent on JNBridgePro-specific overhead. Table 2 shows time spent on a single call/return in the test application when no parameters are passed or values returned. The values come from the typical "string parameters" scenario. Table 2 also shows the overhead involved in passing parameters. This value covers the actual parameter values themselves, plus additional parameter type and encoding identifiers and string length values. The amount of overhead is small, and shows continuous improvement as more powerful Intel processors are used.
Table 2: Time (ms) spent in JNBridge inter-platform overhead (string parameters scenario)
While real-life applications employing Java-.NET interoperability will likely be distributed and reside on multiple machines, the results in this paper suggest that a solution employing JNBridgePro can implement this interoperability with very insignificant overhead.
Applications requiring interoperability between Java and .NET can be implemented using JNBridge's JNBridgePro interoperability solution. And JNBridgePro, combined with Intel Architecture, provides improved performance.
The latest release of JNBridgePro version 1.1 allows .NET code to access Java code that runs under J2EE application servers. In future papers, look to Intel® Developer Services for comparisons of the performance of tightly coupled J2EE and .NET code linked with JNBridgePro with that of conventional interoperability solutions that employ Web services.