Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


Calling Java Classes Directly from .NET  : Page 4

As the frequency of .NET and Java applications increases, we're headed for an interoperability imperative—we have to get both sides to work together. One way to do that is by adding an interoperability layer that gives .NET direct access to Java classes.




Application Security Testing: An Integral Part of DevOps

Setting Up the .NET Program
Double-click on the Project\DotNet\LogDemo.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 Project\DotNet into your build folder, which will either be bin\release or bin\debug, 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 <path to Project\Java>;<path to jnbcore.jar in JNBridgePro installation folder>;<path to log4j- 1.2.8.jar> com.jnbridge.jnbcore.JNBMain /props <path to jnbcore_tcp.properties in JNBridgePro installation folder>

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.

Wayne Citrin is president of JNBridge, LLC, a provider of Java/.NET interoperability tools located in Boulder, Colorado. His main technical interests are in programming language design and software development tools. He has been on the Computer Engineering faculty at the University of Colorado, Boulder, and was a researcher at IBMs research lab in Z�rich, Switzerland. He has an MS and PhD from the University of California, Berkeley, and an AB from Cornell University, all in Computer Science. He can be reached by email here.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.
Thanks for your registration, follow us on our social networks to keep up-to-date