JNI can be used to call C/C++ functions in Java.
You can go through this specification for more details.
But JNI comes at some cost.
1. You have to debug the C function in case of any defect.
2. Your program will no longer remain platform independent.
I've done a lot of work with JNI under Windows and Linux. It has a steep learning curve, but is actually very easy to use once you get past that curve. What I mean is that it is a challenge to learn the techniques that let you call C functions from Java, call Java methods from C, pass values back and forth, and so on, as none of them are particularly intuitive. But, once you "crack the code," as it were, it is quite easy to do these things a second time, and a third, and so on.
Debugging your C code is a bit harder. If you are using the Visual Studio IDE from Microsoft, you can create a DLL in C, then have the IDE start your Java program (by, of course, using java.exe). When your program calls your DLL functions, the IDE will catch your breakpoints and let you debug it. Again, once you learn the trick of having the IDE start your Java program, debugging your C code in the IDE will be fairly easy (well, no harder than any other C debugging you do), but learning getting that trick to work the first time might be a little complicated.
Tapas is quite right: when you embrace JNI, you will no longer be writing platform-independent code. How significant this is depends on how many platforms you expected to run on in the first place. My personal view is that a lot of great programs that could have been written by using JNI were sacrificed at the altar of platform-independence and that many times the sacrifice was to a false god. I also get the feeling that the general community of Java users frowns so much on using JNI that it can be hard to find good tutorials and even harder to find good examples. People tend often to act like you are making a dubious choice if you use it at all. In my case, I am writing programs that need to capture individual frames of video from Webcams, which required that I make use of Microsoft's DirectShow framework. There's no built-in Java support for that and everything I could find was all JNI-based (and tended to be closed source, provided no single-frame capability, or had other drawbacks). So, I wrote my own C functions and used JNI to call them from Java. Works great and actually does help with platform independence because there is no way I could write a Java program to do what I want, yet my Java component will run on any platform that runs Java, and I would have to write a platform-specific component for each platform anyway. That is, Java can't solve my problem in a purely platform-independent way, but I have reduced the platform-dependent part of my problem to a very limited interface, so I can adapt my program to other platforms by doing only what I need to implement that platform on each one.
That said, there are two things I keep in mind about JNI: First, if I am working closely with hardware, I shouldn't be surprised that Java can't do what I need. Java's platform independence comes, in part, from the fact that it runs a virtual machine, and isn't designed to get you close to physical devices (that's a bit vague, but maybe someone else can say it better, contradict me, or both, which often happens here ). Second, I ask myself if I really give a fig about running my application on another system. In my travels, I only ever encounter four kinds of computers: those that run Windows (my target market); those that run Linux (too few on desktops to be a market for me); those that are Macintoshes (too snooty for me to want to deal with); those that are none of the first three (too far down in the weeds to care about). IMHO, a lot of the emphasis on platform independence overlooks the practical aspects of their being Windows, Macs, and Linux as the only platforms likely to run most computer programs the vast majority of Java programmers might ever write, and the need to make a program run on more than one of those easily justifies a bit of platform-specific coding when the alternative is not to write the program at all.
So, yes, JNI may be your answer, and don't be dissuaded by the fact that it is inherently platform-specific. Just try to limit your C code to only what you need to be in C, and use transportable C programming methods as much as you can. If you really do ever have to compile for another platform, you'll probably find it's not a big enough issue to have stopped you from using JNI.
"Il y a peu de choses qui me soient impossibles..."