This content has been marked as final. Show 2 replies
If you have a shared library (dll) that you rely on then by definition you are limited to what that shared library runs on.1 person found this helpful
If that doesn't meet your business needs then your only option is to find another solution.
Other than that you don't need to interact with a shared library via dll. Instead.
1. Create a communication idiom that meets your business needs.
2. Create a C++ console executable that uses 1 and the shared library.
3. Test 2.
4. Write java code that uses Runtime.exec() to run 2 and uses 1 to communicate with it.
The above has the following advantages.
1. When the C++ code and/or shared library blows up (pointer bug) it won't take down your java application.
2. It is easier to test/manage the console exe by itself than attempting to test/manage via JNI.
So, I am not really sure that I have been understood you, but generally you advice me to:
1. make a application on C++ using .dll library
2. make a Java application that communicates with the C++ one
I thought the using Java is the more secure way to do it, but honesty I am no sure what the advantages are because I have dll library and I have to create application using it - ok. But using Java brings me what? Finally, when I am using JNI the native part of the program is the risky one and it depends on the OS because if it.
So, can you light me up is there any positive in doing that on Java, or there is no difference when I have dll library instate of jar one.
Thanks a lot for the spare time on my questions.