devxlogo

Calling Java Classes Directly from .NET

Calling Java Classes Directly from .NET

t’s a fact that most production environments now use a mixture of both Java and .NET, despite all the partisan disputes over which side should “win.” To be prudently responsible in the face of this business reality, it is imperative that developers get both sides to work together. Interoperability is no longer an option: fortunately, you do have some options for choosing the best path for achieving interoperability for your project.

Your specific interoperability needs may vary, based on your current systems and project specifications. Perhaps you already have some perfectly good “legacy” Java code that you don’t need to change, but want to extend with new .NET components. Or, you’re creating a new system, and want to assign tasks to the better-suited platform, so you’re using J2EE’s Enterprise Java Beans (EJBs) for the scalable back-end system, and .NET Windows Forms to create a rich desktop GUI. In either case, you may need direct access to Java classes from .NET. This article briefly discusses the major interoperability methods available and highlights some issues to consider as you make your interoperability selection, and demonstrate class-level interop with a specific example.

Click here to see or hide the author’s description of other interoperability methods.

Runtime Bridges
Perhaps the most natural interoperability method is to run the Java code in a JVM, the .NET code in a CLR, and use a runtime bridge to manage the communications between them. In this scenario, the .NET code calls .NET classes and objects that act as proxies for the Java classes and objects. The proxies manage the communication; the calling .NET classes aren’t even aware that they’re ultimately calling Java classes. A runtime bridge provides interoperability for a wide variety of architectures, because the Java code and the .NET code can be on different machines, the Java code can run in a standalone JVM or in a J2EE application server, and the solution provides interoperability for any JDK version. As with bytecode translation solutions, you need only the Java bytecodes, not the source. There are several runtime bridges commercially available. The code for this article uses JNBridgePro from JNBridge. See the related resources section of this article for other bridge products. In the remainder of this article, you’ll see how to use JNBridgePro to solve a real-world interoperability problem.

Build a Logging Example
Most software systems of any size or complexity contain a logging facility. Good logging packages exist for both Java (log4J) and .NET (log4N, which is the .NET equivalent of log4J). However, if a system contains both .NET and Java components, each side would be logged into its own logging package, which would generate two log files and make it difficult to collate or correlate the events logged. If you could instead use a single logging package to log to a single log file, you could easily see the sequence in which .NET-originated and Java-originated events took place. A single logging package also simplifies handling timing and file access conflicts among the multiple processes and threads attempting to log events. You could choose either a .NET-based or Java-based logging package as the single logging package to be used from both .NET and Java. This example uses the Java-based package log4J to do the logging, but accesses the log from both sides, to demonstrate how transparently .NET can use existing Java classes. The goal is to create a simple application containing both Java and .NET classes, where both the Java and .NET classes use the Java-based log4J logging package. The application has a .NET-based Windows Forms GUI, which calls the Java classes that perform the logging operations. In the remainder of this article, you’ll walk through the process of setting up the interoperability project, creating the proxies, and building and running the project. Requirements
To complete the project, you’ll need Microsoft Visual Studio .NET 2003 and the .NET Framework 1.1 installed on your machine. You can get the project to build using the .NET Framework SDK or Visual Studio .NET 2002, and .NET Framework 1.0, but you will need to make some modifications outside the scope of this article. The JNBridgePro documentation contains some suggestions on how you can proceed with older versions of .NET. On the Java side, you must have a Java Development Kit (JDK) installed on your machine. You may use any JDK of version 1.2.2 or later. You can download a free JDK from Sun’s Java site. Setting up
To set up the project, download the zip file containing the project code and unpack it. The zip file contains two sub-folders, Project and Completed. The Project folder contains all the code needed to create the project. The Completed folder contains the completed, ready-to-run, project, in case you don’t want to create the project yourself. The Project folder contains dotNet and Java folders containing the .NET and Java portions of the project code, respectively. The Java folder contains a single Java class named JavaClass, which exposes a recordEvent() method that logs a supplied message to a specific logging category, as shown below:

   package devX.logging;   import org.apache.log4j.*;   public class JavaClass   {      private static Category cat =    Category.getInstance("JavaClass");      public void recordEvent(String message)      {         cat.debug(message);      }   }

Although you’ll find the source file in the accompanying code, JavaClass is already compiled, so you need do nothing else to it. In addition to Java code, the Project folder contains two .NET C# source code files. Form1.cs defines a Windows application that calls both .NET and Java objects, each of which logs events through the log4j Java-based logging package. The DotNetClass.cs file defines a .NET class similar to the JavaClass mentioned above. The DotNetClass also contains a recordEvent() method that logs a supplied message to a specific logging category:

   using System;   using org.apache.log4j;   namespace LogDemo   {      ///       /// Sample .NET class that calls log4j.      ///       public class DotNetClass      {         private static Category cat =            Category.getInstance("DotNetClass");         public DotNetClass()         {         }         public void recordEvent(String message)         {            cat.debug(new java.lang.JavaString(message))         }      }   }

Category is a .NET class that acts as a proxy for the corresponding Java Category class in the log4j package. .NET code accesses Java classes and objects by interacting with the corresponding proxy object. You’ll see more about proxies and how they’re generated and used in the remainder of this article. The Completed folder contains everything in the Project folder plus additional files that allow the project to run without additional changes. In addition to the project code, download the logging package log4j and unpack it in a location of your choice. Finally, you’ll need JNBridgePro from the JNBridge Web site. For the purposes of this project, you may download either the EE or SE version. JNBridge provides 15 days of free use from the time that you install JNBridgePro; which should be sufficient to complete this project. Install JNBridgePro by double-clicking on the downloaded installation file and following the instructions. Make sure that JNBridgePro is set up correctly by launching the JNBProxy proxy generation tool (through the Start menu or by double-clicking on the desktop icon). The first time you do this, you’ll see a dialog box that allows you to specify the Java configuration (see Figure 1). Make sure to check the “Start Java automatically” checkbox and specify a valid path is specified in the “Locate the java.exe file …” text box. After doing so, click the OK button. You can close JNBProxy at this point, or you can leave it open and proceed to the next step.

Generating Proxies
.NET classes communicate with Java classes through proxy classes. JNBridgePro generates a .NET proxy class for each Java class that you want to access from .NET. The .NET code then interacts with the proxy class, which manages the communication with the corresponding Java class. When you need an instance of a Java class, the .NET code automatically and transparently creates an instance of both the proxy and the corresponding Java object. To call a method on that Java object, you simply call the corresponding method on the proxy object. Similarly, to call a static method, you call the corresponding method on the proxy class, and to access a field in the Java object or class, you access the corresponding field on the proxy object or class. The JNBProxy proxy generation tool creates these proxies and collects them in a .NET assembly, which appears as a DLL file that is linked into the .NET project. To create the proxy assembly, launch the JNBProxy proxy generation tool (if it hasn’t already been launched in the previous section). Specify the locations of the Java class and jar files containing the classes for which proxies will be generated by selecting the Project, Edit Classpath… menu item, and then navigating to the ProjectJava folder, which contains the devX.logging.JavaClass class file, and the file log4j-1.2.8.jar from the unpacked log4j zip file. Click on the OK button when you’re done. Next, load the classes for which you wish to generate proxies into the proxy generation tool. First, select the Project, Add Classes from Classpath… menu item, and then type in the class name “devX.logging.JavaClass.” Make sure to check the “Include supporting classes” checkbox. Checking that option causes JNBProxy to generate proxies for all the classes that you might possibly need when accessing JavaClass. Click on the Add button, then on the OK button. JNBProxy will load approximately 200 classes. Repeat the process to load the logging classes in the log4j-1.2.8.jar file. JNBProxy will load a second set of classes. You’ll want to generate proxies for all the classes you’ve loaded, so select the Edit, Check All in Environment menu item. Finally, select the Project, Build… menu item, navigate to the ProjectDotNet folder, and enter the file name loggingProxies to generate a file named loggingProxies.dll containing the proxy classes. Figure 2 shows how the JNBProxy window looks after building the proxies. Note that you may get a warning message that some possibly required classes are missing. You can ignore this message, because these classes are necessary only if you want to log to other destinations, such as a JMS publisher—and you won’t be doing that in this project.

Setting Up the .NET Program
Double-click on the ProjectDotNetLogDemo.sln file to open the .NET project. Before building the project, add the proxies to the project by adding a reference to the assembly loggingProxies.dll that you created in the preceding section. You also need a reference to the assembly jnbshare.dll that you’ll find in the JNBridgePro installation folder. Jnbshare.dll contains the core JNBridgePro functionality used to manage communications with the Java classes. After adding the references, you should be able to build the project without errors.

Figure 3. Starting the Binary Server: Here’s an example of the command line to start the Java side. Note that your paths may differ from the ones shown here.

To finish setting up the .NET program, copy the file jnbproxy.config from ProjectDotNet into your build folder, which will either be bin elease or bindebug, depending on your Visual Studio project build settings. jnbproxy.config contains configuration information that tells the .NET side where the Java code is located and which protocol will be used to communicate with it. In this case, jnbproxy.config specifies that the Java code is located on the same machine as the .NET code, that it will listen on port 8085, and will communicate with the binary protocol. Running the Program
If you examine Form1.cs, you’ll see that it uses the BasicConfigurator class, which for demonstration purposes causes logged messages to appear in the Java console window. Note that it’s quite possible to log to files, JMS publishers, or other endpoints. Before starting the .NET program, you’ll need to start the JVM containing the Java classes, so they’ll be able to receive the requests from the .NET side. Do this by opening a command-line window and typing in the following command line:

   java --cp ;; com.jnbridge.jnbcore.JNBMain /props    

To be safe, surround each of the paths in the preceding command line with quotes, because they may contain spaces. The jnbcore.jar file contains the core JNBridgePro functionality that allows Java classes to communicate with the .NET side. The jnbcore_tcp.properties file contains configuration information that tells Java which communications protocol to use and which port to listen on for requests. The sample project uses the binary protocol and listens on port 8085. Figure 3 shows what you will see if all goes well.

Figure 4. The Logging Application: The figure shows the .NET front-end application that lets you log messages from either .NET or Java.

Next, start the .NET program from Visual Studio .NET, or simply by double-clicking on LogDemo.exe. Figure 4 shows the running application. Clicking on the “Log .NET event” button causes the DotNetClass to log an event from .NET. Click on the “Log Java event” button to cause JavaClass to log an event from Java. You can either supply a custom message to log or just use the supplied defaults. In each case, the Java-based log4j package performs the logging operation, and displays the logged messages in the console window, as shown in Figure 5. In this project you’ve seen how to log messages from both .NET and Java code into a common logging package—in this case running on the Java platform. Using a common logging package consolidates .NET-originated and Java-originated logging messages in the same console window or file, and lets you easily see the sequence of from both the .NET and Java sides.

Figure 5. Logged Messages in the Console: Here’s how the logged messages appear in the console window.

More generally, you’ve seen how call to Java classes directly from .NET by using a runtime bridge. In the sample application, .NET code calls Java classes in the log4j package, and also calls the Java class JavaClass. You can easily extend this technique of directly accessing Java classes from .NET to other Java class libraries, and you can also use it to let .NET classes access EJBs, JMS queues, or other Java and J2EE capabilities. Using a runtime bridge is simple, transparent, and extensible, because your .NET code accesses the Java code through proxies, and has no idea that it’s talking to Java classes.

devxblackblue

About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist