JuggerNET Introduction

At the beginning of your project is always an integration problem: you have some Java code and some .NET code and the two sides need to work together.

As with any integration problem, there are probably a million ways of solving it. This multitude of integration options is usually constrained fairly dramatically by considerations related to:

• your development team's area of expertise

  Do your developers have the necessary skills to create and maintain an integrated solution using a particular integration technology?

• timeliness

  If you need a working proof of concept in a week you will want something that gets you close to the finish line in a matter of hours or days.

• performance

  If you have to integrate a "chatty" API, you won't want to marshall and unmarshall all the data all the time to cross the language barrier.

• scope

  Your approach might vary depending on whether you have to use one Java type or 1,700 Java types from .NET.

• reliability

  If you are developing an integrated server application or something that has to stay up reliably for long periods of time, you want to make sure there are no unexpected side effects or leaks.

• maintainability

  If the integration is not just a one-time effort but involves products under active development, you have to think about the cost of doing the work once, and then again, and again, and again...

Everything listed above is a consideration that in the past has caused businesses to commit to JuggerNET.

JuggerNET distinguishes itself from most other integration approaches in that it allows you to perform feature-complete API integrations for thousands of types. We have seen customer projects with over 3,000 .NET proxy types being generated, and they all just work.

The integration is very tight and very fast: the language boundary is crossed in-process and usually only incurs the cost of a few additional C-function calls.

Typical Integration Project Workflow

In the typical JuggerNET workflow we always start out with some Java code. You import the Java bytecode into the code generator and set some options that control the conversion of Java types to .NET proxy types. The most user-friendly way of doing this is via the code generator GUI; a screenshot is shown below.

If you focus on just the two main panels in the GUI you will see a tree view of the imported Java types on the left, and a grid view displaying the model properties that control the transformation of Java to .NET on the right.

You manipulate this model until you are satisfied and then you generate your .NET proxy types. These proxy types resemble the selected Java types as much as possible, or better: their usability resembles the usability of the original Java types as closely as possible. You don't really care what the types look like as long as they intuitively work as you would expect them to.

Typically you only have one or a few developers who make themselves knowledgeable about the code generator. These "licensed code generator users" set up the model file and integrate the code generator into your project's build.

Once the code has been generated, the .NET proxy types can be added to your development project, either as a library or directly as source code, and all of your developers can start writing .NET code against them, almost as if they were writing Java code. They neither have to be specially licensed nor have an understanding of how the code generator works.

What Happens When You Launch Your Application?

In addition to the generated .NET proxy types, you also had to add the Codemesh runtime library to your application. The runtime library has all the smarts to load a Java Virtual Machine into your .NET program and to connect the proxy types with their corresponding Java types. All the .NET proxy types then delegate to their original Java types via the Java Native Interface (JNI) when the program executes.

This only works if the runtime library can find a JVM and if the Java types are available. In practice, for a non-trivial application, you have to use the runtime library's configuration API to specify the JVM you want to use and at a minimum set its runtime options (classpath, etc.) so that the Java classes can be found. They are required because the generated .NET types by themselves are quite useless. This is why we call them "proxy" types: they don't do anything by themselves; they just know how to delegate to their Java counterparts which continue to do all the work.

And After That?

You might be done at this point if all you needed was a proof of concept. In all likelihood though, you now need to start thinking about integrating JuggerNET into your product build.

As you will learn if you read more about the code generator, we invested a lot of effort into giving you great automated build integration features. You will be able to use your saved code generator model file in a commandline invocation of the code generator. What's more, you can set it up to use variables, build properties, dynamically discovered files, etc. so that the same file works on different build hosts.