Consume a Java API in C++
This use case takes as many forms as there are Java APIs. We have identified several Java APIs that are very popular with C++ 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 C++ competitors'.
JunC++ion distinguishes itself by offering full API level integration. Whether you're faced with nine or nine thousand Java types, JunC++ion 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 JunC++ion-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 C++ 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.
Native Method Support
We have even provided special features in the code generator to help you implement native methods, which
can be a surprisingly popular use case. Why do we mention this here? Because using our approach
you implement the native method in a typesafe way, using C++ proxy types to deal with the Java method
arguments and return values. Instead of dealing with opaque handles like jstring or jobject
you are given a method that has C++ proxy types as argument- and return-types. When you throw a proxy exception from your
native method implementation it results in a Java
exception being thrown in the JVM rather than a JVM crash.
You are using Java from C++, only to have the C++ used from Java. If that is not the most mind-bending JunC++ion integration scenario, we don't know what is...*
* Actually we do: it's using Java/C++ callbacks in addition to implementing native methods.