Consume a Java API in .NET

This use case takes as many forms as there are Java APIs. We have identified several Java APIs that are very popular with .NET developers, among them the Java Message Service (JMS), Java Database Connectivity (JDBC), NASA WorldWind, several XML APIs, and a bunch of very specialized product APIs.

The reasons can be compelling, for example when the Java product is free and all you have to pay for is the integration cost, or when the Java product's features simply are that much stronger than its .NET competitors'.

JuggerNET distinguishes itself by offering full API level integration. Whether you're faced with nine or nine thousand Java types, JuggerNET can handle the integration.

Because it's so easy — or in other words: inexpensive — to regenerate the proxy types with a later version of the Java API, you can always keep your integration current.

Because the JuggerNET-generated proxy types are just high-performance wrappers around their Java counterparts, you might not even have to regenerate the bindings if you just have a new Java bugfix release that did not change type signatures.

Because the .NET proxy types mirror their Java types' APIs, if there was a breaking API change, you will likely get a compilation error when you recompile your application with the newly generated proxy API. That is a wonderful thing! The compiler will tell you where you need to make a change to react to an API update. Compare that to handwritten JNI bridges that use opaque jobject handles for just about anything.