I am working on building a tool in Java. I need to integrate a big C project with my Java project. So I am using JNI.
I thought that, If I create a new C class that exactly does the same thing with the main class of the project (new C class would be in JNI style), and call it in Java code; I would be able to run the whole C project. I hope I am clear so far.
Here is the class that is supposed to the same things with main class of the C project:
JNIEXPORT void JNICALL Java_CallExact_C_1Main(JNIEnv *, jobject,
jint, jobjectArray) {
PomdpSolveParams param;
//**argc** should be replaced with **jint**
//**argv** should be replaced with **jobjectArray**
param = parseCmdLineAndCfgFile( argc, argv );
showPomdpSolveParams( param );
}
Can anybody tell me how to replace the variables argc and argv with correct parameters?
Related
I will need to use an external, unknown DLL and build a java wrapper around it. I do not have the DLL nor the header file at the moment, and maybe will not even get the header-file, but I'd like to prepare myself. (I have no experience with C++ )
Following situation:
Let's say this DLL has a function, which contains one or more C++ classes as method signature. Then how could I call this function with JNI, as in my java project those custom classes in the DLL are non-existent? Is there a option to "clone" or "port" the C++ class to java? Is there anything I could do with a tool like Dependency Walker to resolve this problem?
What would be the best / most simple approach to accomplish that?
Here is some code which I already tried, to find out how it behaves:
Java Class with main
public class FourthJNI {
public static native int returnAgeOfHuman(int zuQuadrierendeZahl);
public static void main(String[] args) {
// /* This message will help you determine whether
// LD_LIBRARY_PATH is correctly set
// */
// System.out.println("library: "
// + System.getProperty("java.library.path"));
Human testHuman = new Human("abcde", 23, "M");
/* Call to shared library */
int ageOfHuman = FourthJNI.returnAgeOfHuman(5);
System.out.println(testHuman.toString());
System.out.println("Age: " + ageOfHuman);
}
}
generatd h-file
/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class FourthJNI */
#ifndef _Included_FourthJNI
#define _Included_FourthJNI
#ifdef __cplusplus
extern "C" {
#endif
/*
* Class: FourthJNI
* Method: returnAgeOfHuman
* Signature: (I)I
*/
JNIEXPORT jint JNICALL Java_FourthJNI_returnAgeOfHuman
(JNIEnv *, jclass, jint);
#ifdef __cplusplus
}
#endif
#endif
The best way here is to use adapter pattern (https://en.wikipedia.org/wiki/Adapter_pattern). Inside your JNI code you have to call DLL by creating all the objects, as expected by C++ API.
You can find sample here: http://jnicookbook.owsiak.org/recipe-No-021/ and here https://github.com/mkowsiak/jnicookbook/tree/master/recipes/recipeNo025
You can also take a look at the code where one shared library (JNI) calls the code from another one: http://jnicookbook.owsiak.org/recipe-No-023/
Basically, what you have to do is to create JNI based wrapper code that translates Java calls to native methods into C++ calls, and vice versa - the code that translates return values into something that is expected by Java.
I'm trying to get a small/sample Java application, which invokes native C++ code using JNI calls, running on Linux.
I use Eclipse to build, configure the environment and run the application.
I have divided the "overall" project in 2 separate Eclipse projects: 1 Java project and 1 C++ project, containing the native code.
Eclipse project view
The Java part consists of:
1: a "main" class, from which an "adapter" class is invoked to load the .so library and call the native interface/C++ methods
2: an "adapter" class, containing the native method declarations
public class Java_Main_For_So_Kickoff {
public static void main(String[] args) {
// TODO Auto-generated method stub
System.out.println("Hello from Java main!");
Native_Cpp_Adapter adapter = new Native_Cpp_Adapter();
adapter.locSetProperty();
adapter.locLoadLib();
adapter.sayHello();
adapter.test_Kickoff_So_For_Print();
}
}
public class Native_Cpp_Adapter {
public native void test_Kickoff_So_For_Print();
public void locSetProperty() {
"/home/adminuser/workspace_Unit_Test_Java_Cpp/Unit_Test_Cpp/Debug");
String libPathProp = System.getProperty("java.library.path");
System.out.println("lib path set:" + libPathProp);
}
public void locLoadLib() {
System.setProperty("java.library.path",
"//home//adminuser//workspace_Unit_Test_Java_Cpp//Unit_Test_Cpp//Debug//");
String libPathProp = System.getProperty("java.library.path");
String soLibName = "libUnit_Test_Cpp.so";
String soLibWithPath = libPathProp.concat(soLibName);
System.out.println("lib path set for loading:" + libPathProp);
System.load(soLibWithPath);
System.out.println("library loaded");
}
public void sayHello() {
System.out.println("Hello from JNI Adapter (Java part)");
}
}
The C++ part consists of:
1: a *.h file, generated with javah, containing the native method definition
2: a *.cpp file, containing the C++ implementation of the native methods
Both very rudimentary, only meant to sanity-test the JNI environment setup. Added this, omitted that in the original post for this issue.
.h file: Native_Cpp_adapter.h
/*
* Native_Cpp_Adapter.h
*
* Created on: Aug 23, 2017
* Author: adminuser
*/
#ifndef SRC_NATIVE_CPP_ADAPTER_H_
#define SRC_NATIVE_CPP_ADAPTER_H_
/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class Native_Cpp_Adapter */
#ifndef _Included_Native_Cpp_Adapter
#define _Included_Native_Cpp_Adapter
#ifdef __cplusplus
extern "C" {
#endif
JNIEXPORT void JNICALL Java_Native_Cpp_Adapter_test_Kickoff_So_For_Print
(JNIEnv *, jobject);
#ifdef __cplusplus
}
#endif
#endif
#endif /* SRC_NATIVE_CPP_ADAPTER_H_ */
.cpp file: Native_Cpp_Adapter.cpp
#include "jni.h"
#include <iostream>
using namespace std;
JNIEXPORT void JNICALL Java_Native_Cpp_Adapter_test_Kickoff_So_For_Print
(JNIEnv *, jobject)
{
cout << "Correct kickoff of Native JNI method nr. 1";
return;
}
From the C++ project an .so is built, including jni.h and jni_md.h. for the Java project, the resulting .so is included as external library in the Java build path and added as VM argument "java.library.path" in the run configuration (for the applicable Java project/main class).
First, the .so is built from the C++ project: this results in an .so binary in the C++ project folder within the common workspace.
The the Java build is performed. Thereafter the Java program is run invoking the project's main class.
Result: the .so appears to be loaded, but thereafter the process is aborted with an (very persistent) "UnsatisfiedLinkError".
For what I understand, this error is thrown if the Java Virtual Machine cannot find an appropriate native-language definition of a method declared native.
This sounds like the native method definition (C++ side) is not compliant with the native method declaration on the Java-side.
But the C++ definitions are as far as I see/know entirely compliant with the native method declaration in Java, and with the applicable native method naming conventions.
For me, it appears that all building/configuration options are exhausted - does anyone have a suggestion what might be the cause, and to solve this?
It looks like name of your native method is not valid. Make sure to properly escape _ . _ is used to separate packages in native methods. You need to follow naming convention:
https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design.html#resolving_native_method_names
If you have "_" in method name, you need to escape it with "_1" in native code.
Example. For method in Java:
public static native void display_Message();
you need:
JNIEXPORT void JNICALL Java_recipeNo001_HelloWorld_display_1Message
(JNIEnv *, jclass);
Note "_1" that is between "display" and "Message".
Source taken (and slightly modified) from here: http://jnicookbook.owsiak.org/recipe-No-001/
Update
Where should you pay attention:
If everything else fails, make sure to set LD_LIBRARY_PATH before running Eclipse. This will give you some insight whether Eclipse plays nasty or something else is broken
Make sure to pass java.library.path using "-D" while starting your code. You can set it in Debug configuration as JVM arguments
Sometimes, it might be tricky, and it may turn out that your lib doesn't contain symbol at all. You can check it using nm
nm libSomeLibFile.so
You can also set native code location inside project's Properties configuration in Eclipse
Update. I have slightly simplified your code to make it easier to check what is wrong. I suggest you to remove "_" from class names as well as they are again mixed up in native code.
Take a look here:
public class Main {
public static void main(String[] args) {
// TODO Auto-generated method stub
System.out.println("Hello from Java main!");
NativeCppAdapter adapter = new NativeCppAdapter();
adapter.locLoadLib();
adapter.testKickoffSoForPrint();
}
}
Native Adapter class
public class NativeCppAdapter {
public native void testKickoffSoForPrint();
public void locLoadLib() {
String soLibName = "/tmp/libNativeCppAdapter.so";
System.load(soLibName);
}
}
C++ code (pay attention to C export - it has impact on function name !)
#include "jni.h"
#include <iostream>
using namespace std;
#ifdef __cplusplus
extern "C" {
#endif
/*
* Class: NativeCppAdapter
* Method: testKickoffSoForPrint
* Signature: ()V
*/
JNIEXPORT void JNICALL Java_NativeCppAdapter_testKickoffSoForPrint
(JNIEnv *, jobject) {
cout << "Correct kickoff of Native JNI method nr. 1";
return;
}
#ifdef __cplusplus
}
#endif
Compile code and Java
> javac *.java
> c++ -g -shared -fpic -I${JAVA_HOME}/include \
-I${JAVA_HOME}/include/darwin \
NativeCppAdapter.cpp \
-o /tmp/libNativeCppAdapter.so
> java -cp . Main
Hello from Java main!
Correct kickoff of Native JNI method nr. 1
Just few more remarks
If you compile code without
#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
}
#endif
your symbols inside library will be incorrect (not what JVM expects).
Another thing is. If you use "loadLibrary" you have to make sure that file name is in the form: libSomeName.so and you load file via System.loadLibrary("SomeName"); - and you have to make sure that either java.library.path or LD_LIBRARY_PATH point to the file. If you use System.load, on the other hand, you don't have to make any assumptions regarding name. Just make sure you provide full path to file. For example: /tmp/someFileWithMyLib
I need to port a CPP project to Android but I somehow got stuck because of the following things that I am not sure of:
Do I need to use some kind of java wrapper for my CPP project at all, i.e is it necessarily that I use Android SDK to integrate my application with Android? If there is another way, which one would that be?
I have seen some people claiming they have been able to manipulate their cmake file and some custom android-cmake toolchain to build their “.so” or eventually an “.apk” from their project. Would it be possible without a java wrapper to manipulate the cmake files of the cpp project to build your project? (source: Build Android NDK project with Cmake)
From my experience, I would go with using the android java entry point, otherwise you will most likely bump into problems (you can make full native android apps , but I strongly advise against it).
One of the reasons is that you will want SDK function calls from inside your CPP, and using reflection on the java environment from CPP isn't trivial.
The steps would be the following :
Create a very simple C code that will server as bridge to your CPP code . Here are some sample C functions that I've commonly used :
OnApplicationStart
OnApplicationPaused
OnApplicationResumed
OnApplicationUpdate
OnTouchReceived
Export these functions and load them in your Java code (lookup JNI on how to do this)
Handle all Android-specific actions in Java, and all application specific actions in cpp
So the answer to your 1st question is that a java wrapper isn't mandatory, but it's HIGHLY recommended.
To answer your 2nd question :
Yes, you can use cmkae, ant, cygwin , allot of command tools that will end up creating your apk (It's up to you on how you feel comfortable).You will still use the android compiler since you are targeting arm.
The difference is that you need to change in your manifest.xml the entry point of the application from a normal activity to a native activity ( http://developer.android.com/reference/android/app/NativeActivity.html ) .
As you can see, the difference isn't the build system, it's the way you define your entry point.
As a friendly advice, try using the minimal java wrapper approach. You might get to better results sooner, and it won't take you more then 1 week of research on the web on how to link java code to cpp.
EDIT :
As of demand, I will shortly explain how I would approach the process of porting a CPP application to Android :
Rethink your application to work as a shared library , using a C entry point :
a.Create a simple C application that will load yourCPPApp.dll (or .so if you are on linux)
b. In your .dll create the minimum necessary extern "C" functions to be exported in order for you to give the necessary information to your dll
For simplicity, we'll assume we have 3 methods :
void StartApplication();
bool OnApplicationUpdate();
void OnScreenTouched(int x, int y);
c. Implement the simple C project that will make the calls to these methods externaly (so the .exe will call the methods from the .dll ! )
Sample code :
#include "myCPPapp.h"
int main(int arg, char** argv)
{
StartApplication();
srand(time(NULL));
while (OnApplicationUpdate())
{
// we assume we have a 480x640 resolution
OnScreenTouched(rand()%480,rand()%640);
}
return 0;
}
Now that we have things working in full native with a .exe and a .dll , time to make it work with a .apk and a .so
a. Rename the exposed methods from myCppApp into java compatible prototypes
extern "C" {
JNIEXPORT void JNICALL Java_com_sample_nativebridge_OnApplicationStart(JNIEnv env, jobject thiz);
JNIEXPORT jboolean JNICALL Java_com_sample_nativebridge_OnApplcationUpdate(JNIEnv env, jobject thiz);
JNIEXPORT void JNICALL Java_com_sample_nativebridge_OnScreenTouched(JNIEnv env, jobject thiz, jint x, jint y);
}
b. create the java class nativebridge (case sensitive) in the package com.sample (you need t respect the names in order for correct linkage to native)
class nativebridge {
public static native void OnApplicationStart();
public static native boolean OnApplicationUpdate();
public static native void OnScreenTouched(int x, int y);
}
c. add the load library statement in the native bridge in order to have your library loaded at runtime
class nativebridge {
....
static {
System.loadLibrary("myCppApp");
// notice that the lib prefix and .so sufix aren't part of the name
}
}
d. compile your CPP code with the armeabi compiler and create libmyCPPApp.so (ndk build system , or whatever you'd like... i would go with the ndk, it's quite easy , just go into the folder with Android.mk and call $ANDROID_NDK_BUILD_PATH/build )
At this point you will need to createa a .mk file that will compile your myCppApp code, but this is out of scope, you will need to do this research on your own (it's quite trivial once you get the hang of it).
c. use the native methods from the bridge inside your java app wherever you see fit.
A very good tip would be to go through a hello world sample of ndk :
http://www.ntu.edu.sg/home/ehchua/programming/android/android_ndk.html
Enjoy.
I am trying to call a simple native method in Java from C++, to achieve this I do the following:
Create a simple class as shown below:
public class HelloNative{
public native void printString(String str);
static{
System.out.println("Current Directory is: " + System.getProperty("user.dir"));
System.load(System.getProperty("user.dir") + "/libhellonative.so");
}
public static void main(String[] args){
System.out.println("Calling Native Libraray (libhellonative.so) method printString");
new HelloNative().printString("Message from Java to C");
}
}
Create .h file for the native method using javah -jni which create the following declaration:
JNIEXPORT void JNICALL Java_HelloNative_printString(JNIEnv *, jobject, jstring);
Implement the native function in .cpp file as:
JNIEXPORT void JNICALL Java_HelloNative_printString(JNIEnv* jni_env, jobject java_obj, jstring msg){
printf("inside native method\n");
jboolean iscopy;
const char *message = (jni_env)->GetStringUTFChars( msg, &iscopy);
printf("%s", message);
}
And finally create the .so file using:
g++ HelloNative.cpp -o libhellonative.so -shared -Wl,-soname,libhellonative.so -static -lc -I /usr/lib/jvm/java-6-sun-1.6.0.26/include -I /usr/lib/jvm/java-6-sun-1.6.0.26/include/linux
But when I compile and run the .java file it's giving me Runtime Exception:
Current Directory is: /home/gmuhammad/Projects/test
Calling Native Libraray (libhellonative.so) method printString
Exception in thread "main" java.lang.UnsatisfiedLinkError: HelloNative.printString(Ljava/lang/String;)V
at HelloNative.printString(Native Method)
at HelloNative.main(HelloNative.java:16)
Ok, I got this to work. It has nothing to do with loading the library, but with actually calling the method from that library.
I created .java, .h and .cpp files by copy/paste from your question and ran them (I had to add #include <jni.h> in the .cpp file) - and got exactly the same error as you did.
Then I edited the .cpp file to include the generated .h file. Also, as maba indicated in his answer, you need to call (jni_env)->ReleaseStringUTFChars(msg, message); to release the object. My full .cpp file now looks like this:
#include "HelloNative.h"
JNIEXPORT void JNICALL Java_HelloNative_printString(JNIEnv* jni_env, jobject java_obj, jstring msg){
printf("inside native method\n");
jboolean iscopy;
const char *message = (jni_env)->GetStringUTFChars( msg, &iscopy);
printf("%s", message);
(jni_env)->ReleaseStringUTFChars(msg, message);
}
I re-compiled the library, ran the java code - and voila! everything works. This way, it works regardless of which way you load the library, with load or loadLibrary.
Give it a try.
I recommend to load the library slightly differently.
Place your libmynative.so into whatever directory you like.
Add that directory to LD_LIBRARY_PATH variable.
In your java code, change System.load call to be System.loadLibrary("mynative") (note the lack of full path, prefix lib and extension .so)
Run your java code.
Have a look here for more details: http://java.sun.com/developer/onlineTraining/Programming/JDCBook/jniexamp.html
It is totally OK to use the System.load() but you will have to be sure that your shared libraries really are where you say they should be.
Current Directory is: /home/gmuhammad/Projects/test
Your code is trying to access the shared library in that directory. Are you sure that the libhellonative.so is there?
Then you can also use the System.mapLibraryName("hellonative") to get the name of the shared library for the current platform. That makes it more platform independent. The call will give you libhellonative.so on linux and hellonative.dll on windows.
Also you must call (jni_env)->GetReleaseUTFChars(msg, message); to release the objects.
I have a custom dll that I access from Java using JNA. So far all is working perfect. Now however I would like to create Java classes from my C code. I assume this can't be done with JNA so what I did is to create a JNI method but this leads me to UnsatisfiedLinkError's. So my question is: Can I mix JNA and JNI when accessing the same DLL and if so, how should I go about doing that?
Of course can you mix access to the DLL, since it is only loaded once anyway. The problem is how the linking to your application works:
JNA:
When using JNA you call the native functions of the jna library, which by some kind of reflection bind to the functions in your DLL. This has the advantage that you don't have to worry about the name of the functions in the DLL, they don't have to meet any conventions.
JNI:
Simple works by a mapping from your java classes to method names which are expected in the DLL. If you have a Class com.company.SomeClass containing a function int doStuff(int i, long john) with this signature:
JNIEXPORT jint JNICALL Java_SomeClass_doStuff(JNIEnv *env, jint i, jlong john) {
return ...whatever...
}
If this function is missing, you get the UnsatisfiedLinkException.
Solution:
Since it seems you have written your own DLL, just add the functions required as wrapper functions, and you are done. To get the function signatures, you can create a header file automatically with the javah command.
I recommend reading Advanced Programming for the Java 2 Platform - Chapter 5: JNI Technology.
I want to add one thing to do that. Don't forget extern "C" for each JNIEXPORT and also function for JNA.
As a simple example:
// Example DLL header file MyDLL.dll
#ifdef MYDLL_EXPORTS
#define MYDLL_API __declspec(dllexport)
#else
#define MYDLL_API __declspec(dllimport)
#endif
extern "C" {
MYDLL_API void HelloWorld(void);
}
extern "C" {
JNIEXPORT void JNICALL Java_MyJavaMain_HelloWorld(void);
}
//Example CPP file MyDLL.cpp
#include "MyDLL.h"
#include "stdio.h"
extern "C" declspec(dllexport)
void HelloWorld(void){
printf("Hello World From Dll");
}