Wrapping C/C++ inside Java - java

I develop applications/programs in C/C++. I am more versed in these two languages and love being a C++ developer. I am wondering how to create a Java program that contains all my C++ code.
I mean, I would like to wrap all my C++ code (that is already developed) inside Java class. But clueless how to do it.
Please post your responses or methods/steps on integrating C++ inside Java.
(using JNI is the way, but I could not figure it out on www how to use it)
FYI, I use Eclipse IDE to develop.
How and what packages should I include in my project workspace?

Instead of JNI, or JNI with some assist from an automatic wrapper generator like SWIG, or even JNA, you might consider separating the C/C++ and Java into separate processes and using some form of IPC and/or Java's Process abstraction to call to a program written in C/C++. This approach abandons "wrapping," so in some sense it isn't an answer to this question, but please read on before down-voting. I believe that this is a reasonable answer to the broader issue in some cases.
The reason for such an approach is that when you call C/C++ directly from Java, the JVM is put at risk of any error in the native code. The risk depends somewhat on how much of the native code is yours and how much you link to third party code (and how much access you have to the source code of such third party code).
I've run into a situation where I had to call a C/C++ library from Java and the C/C++ library had bugs that caused the JVM to crash. I didn't have the third party source code, so I couldn't fix the bug(s) in the native code. The eventual solution was to call a separate C/C++ program, linked to the third party library. The Java application then made calls to many ephemeral native processes whenever it needed to call the C/C++ stuff.
If the native code has a problem, you might be able to recover/retry in Java. If the native code is wrapped and called from the JVM process, it could take down the entire JVM.
This approach has performance/resource consumption implications and may not be a good fit for your application, but it is worth considering in certain situations.
Having a separate application that exercises the functionality of the C/C++ code is potentially useful as a stand-alone utility and for testing. And having some clean command-line or IPC interface could ease future integrations with other languages.
As another alternative, you could get into native signal handling to mitigate the risks to the integrity of the JVM process if you like and stick with a wrapping solution.

If you want to call C++ from Java, you'll need to use JNI - Java Native Interface.
Be warned that you lose some of the benefits of the garbage collector, since it can't deal with your C++ objects, and your code won't be portable anymore.
Maybe you'd be better served by learning to write 100% Java and leaving C++ behind, but that's just a suggestion.

You can't "just wrap it", you have to write some C/C++ glue.
For starters, SWIG can do most of the works for you.

There are plenty of tutorials for doing exactly what you want to do. For example, check out: http://www.javamex.com/tutorials/jni/getting_started.shtml
There are also plenty of caveats of using JNI. I've recently started working with it (just for fun, really), and it tends to be a lot less fun than I had first anticipated.
First of all, you have to deal with cryptic code such as:
#include "test_Test.h"
JNIEXPORT jint JNICALL Java_test_Test_getDoubled(JNIEnv *env, jclass clz, jint n) {
return n * 2;
}
Second of all, it tends to downplay one of the primary reasons why you use Java in the first place: WORA (Write Once, Run Anywhere). As duffymo mentioned, there can also be issues with the garbage collector, but I think that in recent years, the JVM has gotten pretty smart about JNI integration.
With that said, to port all of your C++ code to JNI, you'd need to refactor your interfaces (and maybe even do some internal gymnastics). It's not impossible, but it's really not recommended. The ideal solution is just re-writing your code in Java.
With that said, you could also "convert" your code from C/C++ into Java programatically, and there are multitudes of such utilities. But, of course, machines are dumber than people and they are also bound to make mistakes, depending how complex your class is.

I would avoid JNI because it's tedious to write, verbose, and just an altogether pain. Instead I'd use JNA library which makes writing native integration so simple.
https://github.com/twall/jna/
Good luck.

You can write C++ code through JNI but there isn't a direct mapping from C++ classes to Java classes.
I've used JNI to fix problems found in the android SDK (specifically, an incredibly slow FloatBuffer.put implementation) and I may end up using it for some performance critical areas. My advice would be to be use it sparingly and in a duck in, do the performance critical stuff and leave, without doing any memory allocation if you can help it. Also, don't forget to measure your code to see if it really is faster.
Out of interest, what platform are you developing for? The only platform where it would make sense to wrap a lot of C++ code in a light java layer would be Android - on other platforms, just compile in C++ and have done with it.

JNI module is not a Java classes. It's C. Using JNI incur many restrictions and some Java environment doesn't support JNI well.
There is no supported way of "wrap my C++ code inside Java class" (EDIT: I mean, without JNI noway but JNI is problematic.)
You could investigate custom C++ compiler emit Java byte codes, but nobody (include me) will recommend this approach.

BridJ was designed on purpose for that (and it's supported by JNAerator, which will parse your C/C++ headers and spit out the Java bindings for you).
It is a recent alternative to JNA, with support for C++.

Related

How can I leverage C++ code in the JVM?

I'm working with a project that was built in C++. Within this project are public classes that contain public methods that I would like to call from my Java code. What's the best way to make this happen? I imagine I'd want something that would compile the C++ code down to bytecode.
I've seen a couple tools that do something like this, but some of them have not been updated for a very long time, and others seem inappropriate for the task. Are any of these tools mature enough to be used for a professional-grade app? Although open-source is preferable, I'm equally willing to consider commercial tools.
I am currently using a package aptly named javacpp. I believe it is worth taking a look at
There's always the old standby, JNI, known for being slow and very hard to use.
JNA is something I've never used personally but "I've heard good things" and it looks like it might fit your bill.
An alternate and potentially better approach would be to restructure your C++ code as a service that listens on e.g. TCP or UNIX sockets. This would increase the portability, make it possible to connect to it from most languages, and is not Java-specific.
Bridging C++ to Java using JNI (Java Native Interface) is actually pretty easy. Downside is you need to compile the C++ part for the platforms you want the code to work with.
I've got an example of calling Java from C++ in this post Can C++ call Java code? but calling C++ from Java is quite similar.

J++ to Java: how to migrate from RNI to JNI?

I've inherited a legacy J++ project. I've upgraded this project to standard Sun Java successfully.
However, this project includes a native C++ dll which the Java code talks to via the Microsoft-specific RNI framework.
Needless to say, calling System.loadLibrary("myRniNativeDll") now throws a UnsatisifiedLinkError, saying one of the dependencies couldn't be found.
I'm totally clueless how to migrate a C++ RNI dll to a JNI dll; I've no idea where to begin. I have the C++ source code, but I don't know how to build a JNI dll. Are there any tips/tutorials/online materials you Java experts can point me to?
If the licensing is acceptable (LGPL), Java Native Access provides a rather friendlier FFI than the JNI does; porting may reduce to stripping away the RNI layer and just exposing a simple 'C'-callable API.
Take a look at JNA - it might be possible to access the RNI DLL directly that way; or at least it will make the job of porting it much easier than doing JNI manually.
If possible, I suggest that you consider avoiding the RNI -> JNI porting problem by rewriting the C++ code in pure Java.
Writing JNI code requires a huge amount of care, and places JVM stability at risk if you get it wrong. My advice is to avoid it if you possibly can.
While I have never used Microsoft's RNI, only Sun's JNI, I would expect that you couldn't directly use an RNI-style DLL as if it were a JNI-style DLL. I am also unaware of anything that would automatically convert or bridge RNI to JNI.
You do not mention if you have the source to the C++ RNI DLL, although I'll assume you do since you mention inheriting the project. If you have any C++/C experience, and have a good idea of what functionality the RNI DLL is providing, it should not be too difficult to move it to JNI. The time invested in porting it would likely pay off for maintaining it moving forward.
The link you provided to the JNI entry on Wikipedia has lots of helpful links on coding with JNI. Without a bit more detail, it is hard to give any other advice.
Java Native Interface: Programmer's Guide and Specification is the best resource that I've found for writing JNI code. It doesn't cover RNI -> JNI, but it is a great* starting point for learning how JNI works.
*It's actually very dry, and not particularly fun to read, but it's the best I've been able to find.

Which is the fastest way to access native code from Java?

Which is the fastest way of calling a native library from Java?
The ones I know about are
NativeCall - what we're currently using
JNA - haven't used it, but looks reasonable
JNI - looks horrendous to write, but we'll do it if we get the speed
Swig makes JNI easier too.
In terms of speed, I suspect there will be subtle variations - I strongly suggest you pick a call that you know you'll be making a lot, and benchmark all of the solutions offered.
JNI is the fastest. JNA is very slow compared to JNI (the call overhead is probably one order of magnitude), but it is a fantastic library because it makes native access so easy. JNA is great if you need to make an occasional call to some native API. If you care about performance, I wouldn't use it in any "tight loops."
I'm not sure where NativeCall fits in the spectrum.
Quite a few parameters influence the performances of interfaces between programing languages: what device the JVM runs on, who developed it (in case it's not the usual Sun JVM), whether you will need to call back Java code from native code, the threading model of the JVM on your operating system and how asynchronous will the native code be...
You may not find a reliable benchmark that measures exactly what you need, I'm afraid.
This blog entry claims that due to the introspection mechanisms used by JNA, it'll be significantly slower than JNI. I suspect that NativeCall will use similar mechanisms and thus perform in a similar fashion.
However you should probably benchmark based on the particular objects you're referencing and/or marshalling between Java and C.
I would second the recommendation of SWIG. That makes life particularly easy (easier) for the Java/C interfacing.

Best way to access Java classes from C++? (better than using JNI directly)

I have to integrate a large Java library in a quite large C++ application. A solution is to use JNI but this requires to hand code all the classes. Python has, for example, a wonderful solution with JPype (http://jpype.sourceforge.net/) that automatizes the process (although the same solution cannot be applied to C++ due to C++ and Python different natures).
Thanks,
Das
SWIG is a tool that lets you auto-generate bindings from one language to another. It supports C++ and Java and a dozen other languages.
Seems that my question was not clear enough. Maybe the confusion comes from JNI that allows the access in booth directions ...
What I want to do is to access a Java library FROM C++. That is, someone give me a JAR file that contains a collection od JAVA compiled classes and I must write code in C++ to access it (as I want to integrate the functionality of that Java library into a C++ application).
Hope that this clarifies the direction of access :)
Thanks,
Das
Not sure if this commercial tool makes life any easier, but you might wanna explore -- http://www.teamdev.com/jniwrapper/index.jsf
JNA is not quite what you're looking for, but it does make your life a lot easier. It doesn't require any boilerplate/generated code - you just write an interface for the methods you want to call.
Certainly, there is every reason to use JNA instead of JNI.
I have two suggestions which may or may not work for you:
First, you could try something very simple. Run the Java code in a separate process, and communicate with it with pipes or sockets. This is fairly easy to do, and doesn't require any crazy libraries. The downside is that the communication is somewhat limited (just some simple pipes), you'll need to write your own wrapper around it to send data across
Secondly, what exactly is this library? Perhaps we can suggest alternatives that are not written in Java, that would be much easier to use in your C++ application?

What's the easiest way to use C source code in a Java application?

I found this open-source library that I want to use in my Java application. The library is written in C and was developed under Unix/Linux, and my application will run on Windows. It's a library of mostly mathematical functions, so as far as I can tell it doesn't use anything that's platform-dependent, it's just very basic C code. Also, it's not that big, less than 5,000 lines.
What's the easiest way to use the library in my application? I know there's JNI, but that involves finding a compiler to compile the library under Windows, getting up-to-date with the JNI framework, writing the code, etc. Doable, but not that easy. Is there an easier way? Considering the small size of the library, I'm tempted to just translate it to Java. Are there any tools that can help with that?
EDIT
I ended up translating the part of the library that I needed to Java. It's about 10% of the library so far, though it'll probably increase with time. C and Java are pretty similar, so it only took a few hours. The main difficulty is fixing the bugs that get introduced by mistakes in the translation.
Thank you everyone for your help. The proposed solutions all seemed interesting and I'll look into them when I need to link to larger libraries. For a small piece of C code, manual translation was the simplest solution.
On the Java GNU Scientific Library project I used Swig to generate the JNI wrapper classes around the C libraries. Great tool, and can also generate wrapper code in several languages including Python. Highly recommended.
Your best bet is probably to grab a good c book (K&R: The C Progranmming language) a cup of tea and start translating! I would be skeptical about trusting a translation program, more often then not the best translator is yourself! If you do this one, then its done and you don't need to keep re-doing it. There might be some complications if the library is open source, you'll need to check the licence carefully about this. Another point to consider is that there is always going to be some element of risk and potential error in the translation, therefore it might be necessary to consider writing some tests to ensure that the translation is correct.
Are there no JAVA equivelent Math functions?
As you yourself comment the JNI way is possible, as for a c compiler you could probably use 'Bloodshead Dev-c++' might work, but it is a lot of effort for ~5000 lines.
I'd compile it and use JNA.
JNA (Java Native Access) is basically does in runtime what JNI at compile time and doesnt need any non-java code (not much java either).
I don't know about its performance or usability in your case but I'd give it a try.
Are you sure you want to use the C library, even if it is that small?
Once 64 bit gets a little more common, you'll need to start building/deploying both 32 bit and 64 bit versions of the library as well. And depending on what the C code is like, you may or may not need to update the code to make it build as 64 bit.
If the C library is simple, it may be easier to just port the C library to pure java and not have to deal with building/deploying a JNI library, the C library and the java code.
Well, there is AMPC. It is a C compiler for Windows, MacOS X and Linux, that can compile C code into Java Byte Code (the kind of code, that runs on a Java virtual machine).
AMPC
However, it is commercial and costs $199 per license. I doubt that pays off for you ;) I don't know of any free compiler like that.
OTOH, Java and C are pretty similar. You could probably refactor the C Code to Java (structs can be replaced with objects with public instance variables) and pointer operations can usually be translated to something else (array operations for example). Though I guess you don't want to go through 5,000 lines of code, do you?
Using JNI makes the code platform dependent, however if you say it is platform independent C, there is no reason why your Java code should be platform dependent. OTOH, depending on how costly these calculations are, using JNI might actually buy you a performance gain, as when it comes to raw number crunching throughput, C can still beat Java in speed. However JNI calls are very costly, so if the calculation is just a very simple, quick calculation, the JNI call itself might take equally long (or even longer) than the calculation performed, in which case using JNI will buy you nothing, but slowing down your app and causing memory overhead.
Indeed, JNA looks impressive, it requires less effort than directly using JNI. But in any case you'd lose the platform independence, and since you're probably only using a small part of it, you might consider translating what you actually need.
Have you tried using:
System.loadLibrary("mylibrary.dll");
Not sure if this will work with a pure C library but it's probably worth a shot. :)

Categories