Fer has posted 2 posts at DZone. View Full User Profile

Melting down the JDK/.NET barrier with javonet

07.25.2014
| 3450 views |
  • submit to reddit

Java to .NET bridge concept

 

Enterprise systems usually rely on isolation to become manageable.  Integration patterns take the center of the scene to glue up components at a very high cost that includes marshalling, remote calls, serialization, messaging, and so on.            

Local systems, on the other hand, can’t afford (or shouldn’t?) the cost of establishing all these adapters and data transformations to make use of technology or libraries that are available locally as part of the underlying system architecture.

That’s when bridges between technologies come to the rescue and for Java decision makers interested in integrating .NET technologies into their systems, javonet is the one delivering such good news.            

javonet makes calling .NET objects from Java code possible as it’d be integrated in our local JDK

Regardless of the type of application you’re writing (web or standalone), you can call any method on any .NET object with a reflection style invocation. It just can’t get simpler than that.

          

Sample usage

       

Installation of javonet consists in no more than downloading a jar and activating its license. After that you’re ready to make use of any .NET library you want to.            

Let’s take a sneak peak into javonet’s potential by dealing with one of the most ancient java desktop application’s drawback: the UI.

Every experienced java developer faced this task at least once: try to make your UI as native as you can. You know you can’t get the same results without spending hours trying to find the right way to do it.            

Wouldn’t it be great if you could just open window dialogs natively? Taking it one step further, wouldn’t it be nice to use that neat third-party library based on the latest .NET service pack you heard your .NET developer friends talk about so much? You could. Or you could just sit and wait for Swing/AWT to adopt it (or start contributing to an open source project yourself for that matter).

Let’s get started as quickly as we can. Assuming you have your Java environment ready, Maven installed and your favorite IDE at hand, go through this steps:            

             
  1. Go to http://www.javonet.com/ and follow the instructions
  2. Got your jar file ready? Great; let’s add it to our repository (this is just me being picky, you can avoid this step)
    mvn install:install-file -Dfile=javonet_1.4hf2.jar -DgroupId=com.javonet -DartifactId=javonet -Dversion=1.4hf2 -Dpackaging=jar
  3. Create a simple empty project
    mvn archetype:create -DgroupId=com.javonet -DartifactId=javonet-sample-project
  4. Add the dependency to your pom
    <dependency>
         <groupId>com.javonet</groupId>
         <artifactId>javonet</artifactId>
         <version>1.4hf2</version>
    </dependency>         
  5. Get it into your classpath (I’m using Eclipse)
    mvn eclipse:eclipse         
  6. Let’s code
  7. public class App {
          public static void main(String[] args) throws JavonetException {
                  Javonet.activate("your@email.com", "YOUR-LICENCSE-KEY", JavonetFramework.v40);
                  Javonet.addReference("Ookii.Dialogs.dll");
    
                  NObject dialog = Javonet.New("Ookii.Dialogs.InputDialog");
                  dialog.set("WindowTitle", "javonet did this!");
                  dialog.invoke("ShowDialog");
          }
    }	

Just by reading at the code above you know something great is going on here. I’ve just used a .NET library called Ookii http://www.ookii.org/Software/Dialogs/ (probably that one your friend from the other side talked you about) from Java. And how does it look like?

     

I’m using Windows XP, Classic theme, and that’s how I’d expect a native dialog to be shown... Let’s try the same InputDialog using Swing.


As you can see, this one doesn't look very good and definitively not native.

As previously stated, this is just an example; a simple but powerful demonstration that making use of native libraries pays off at a relatively low cost.            

We’ll go through those details in code I’m sure you considered suspicious in the next section. Worry not, I’m as skeptical as you are when it comes to this sort of reading.

            

Looking further

     

Let’s take a second look at the code. Those set up lines in the beginning don’t look good. I wouldn’t like to reference the packed libraries I’m using programmatically. We know that as our codebase grows that can lead to a huge maintenance problem, impacting in our technical debt.

Luckily, we have a workaround, achieving the same results using XML externalized configuration:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<javonet>
      			<!-- optional -->
      			<references>
	        		<reference>Ookii.Dialogs.dll</reference>
	      		</references>
		      <!-- mandatory -->
		      <activation>
		        <username>YOUR NAME</username>
		        <email>your@email.com</email>
		        <licencekey>YOUR-LICENSE-KEY</licencekey>
		      </activation>
		      <!-- optional (default .NET v35 and MTA) -->
		      <settings>
		        <framework>v40</framework>
		      </settings>
</javonet> 

That helps get our code cleaner. Let’s see what we have so far,

		NObject dialog =Javonet.New("Ookii.Dialogs.InputDialog");
		dialog.set("WindowTitle","javonet did this!");
		dialog.invoke("ShowDialog");

In the first line we’re creating an instance of the InputDialog class. In the Java side of things, every instance is wrapped in an NObject object which has a minimal but cohesive set of methods to make calls on the underlying .NET object.

A full integration toolkit

We’ve gone through the basic usage of this bridge but there’s a lot of room yet to cover.

Some of the features anyone would be interested in before adopting a solution like this one would be the following

  •   Static and instance methods invocation, including getters and setters 
  • Generics support 
  • Collection support 
  • Garbage collection 
    • A garbage collected in Java will be disposed in .NET 
    • Disposing objects by hand is available as well by calling NObject.dispose() 
  • Passing arguments by reference, by value and in out mode 
  • Access to nested types 
  • Enum support 
  • Event listening support 
  • Exception handling
    • A single JavonetException wraps any exception on the .NET side; then you apply your handling logic as needed

javonet gets your back on all of these and there are some other interesting features that really go the extra mile, like       
             
  • A fluent interface which helps you offer cleaner code
  • Calling overloaded methods passing an identifiable null as argument         
  • Debug support for both Java and .NET code               
    • That’s right, debug Java using Eclipse/NetBeans then switch to VisualStudio to debug .NET code                
  • An online API LAB for you to test all the features               
    • If you ever played with Google’s OAuth playground and loved it, this is for you                   

Conclusion

From my humble opinion, judging by the ease of use I've noticed while writing this article and the achievements I could make with little effort, it looks to me that the javonet team is focused on continuously improve their solution. 

As you can see it’s all wrapped up nicely for you to start trespassing the programming language barrier and leverage the usage of .NET technologies in your Java apps.

Published at DZone with permission of its author, Fer Troya.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)