Interoperability without the network : JNI, .NET & DLLs
By Daniel Rubio
[Posted by J.Vaughan]
A non-networked application may seem unthinkable in this day in age, but its often designed in this manner to satisfy everything from infrastructure limitations to thwart security breaches, in the context of .NET and Java interoperability, there are a series of considerations to take into account for achieving such cross-platform communication, some of which we will explore in this last entry on interoperability without web services.
The first and obvious characteristic in this type of scenario is that communication is devoid of any common protocol between platforms such as HTTP for web apps or IIOP for CORBA which implies communication is established directly tapping Java or .NET classes that are managed by either a JVM(”Java Virtual Machine”) or CLR(”Common Language Runtime”), respectively.
The biggest hurdle in each of these cases, is that both a JVM and CLR interpret instructions in different form, in Javas case as byte-code(.class files) and in .NETs case as MSIL code(.dll files). Here once again, before proceeding I should mention there are numerous commercial offerings and other open source projects like Caffeine which offer distinct approaches to solving this particular problem, so as in the previous interoperability entries, this is just but one possibility that doesnt require third party tools, albeit one which might be considered a “long-route” by many.
Our interoperability scenario will involve invoking compiled .NET logic from a Java environment. In Javas case, the language along with its development kit is equipped with the necessary tools to execute non-Java code via JNI(Java Native Interface), however, in the particular of .NET DLLs there is a certain twist you should be aware of, from a Java standpoint compiled .NET code in either of its implementing languages C, VB.NET C++.NET is not considered native but rather managed code.
The advent of .NET has eliminated many of the issues related to native code such as memory management but this same insulation has in itself created an additional barrier to invoke this type of code from lower level interfaces available in other programming languages, and for which JNI was designed, so in other words, Java JNI cannot just call any function in any .dll, as many JNI tutorials lead to believe.
The solution to communicate with .NET DLLs from Java JNI then is to establish communication via a native DLL wrapper also known as non-managed code. So lets start with our .NET code, which is illustrated in Listing 1.1
Simple enough, now lets illustrate the non-managed C++ wrapper for this .NET class
The wrapper makes use of mscorelib.dll which is central to the .NET runtime, and JavaNetInterop.netmodule which is a compiled structure created from the .NET class similar to an assembly as would be JavaNetInterop.dll the rest is compromised by C++ wrapping.
Armed with the C++ wrapper, we would then need to create a header file C++ speak using Javas javah utility, which would later be used for creating our JNI implementation illustrated in Listing 1.3
The top most declarations are used for accessing JNIs header file, the C++ header file and non-managed C++ file, respectively, while the method is used for invoking the wrapping C++ logic. Finally, our last step would be creating a Java calling class that would look something like the following listing :
In this last snippet we make use of the native keyword to indicate we are dealing with a non-Java method, the System.loadLibrary declaration to load the JavaNet dll corresponding to the compiled non-managed C++ wrapper and a main method which creates an object instance while invoking the native method interopLogicMethod.
Though the process is somewhat elaborate, it will nevertheless allow you to call .NET logic from a Java environment. With this we come to a conclusion on our four part series dedicated to exploring non web-services technologies for Java and .NET interoperability. The next time you are faced with a project involving interoperability issues, be sure to give these alternatives a closer look, especially if your organization is still tied-up deciding when,where and if web services should be used.
Leave a Reply