I have a dll created out of a C#.NET project and I would like to call the methods from a java program. I was wondering as to what sort of opportunities exist to accomplish this and then I came across JNA and JNI. Which one should I use for my purpose? Any suggestions? All I need is to call the methods in a class written using C#.NET and process the results from my Java program.
It would depend on your application, But you could place the C# DLL within a service e.g. WCF and expose the functionality to the Java code that way. Using wsimport to generate your client code within Java.
It saves the need to use cross over tools like JNI...
Related
I am new to native code programming in java. i have client dll where they have exposed apis and also given api document.I want to use them in java.
I have written some code to load native library using system.loadLibrary and declared few native methods and able to call them successfully.
But they have some callback methods as well and few data structures that needs to be passed. I have written simlar classes in Java seeing their api. But it is not working.
i am confused about JNI or JNa uses. do I need to use them and create any header files as I already native methods are implmented.
i suppose jni to be used only when we need to develop some part of code in other language like c c++.
Creating header files and then implementing and creating dll. But thats already with me.
Whats the way to easily write those typedef in java??
and is my understanding correct that i dont need jni or jna for this?
I have existing cpp files from a project which I would like to use it for my application which is in Java. I cannot change the cpp files. How can I call the functions from Java?
I'm working in Windows 10 using JavaFX for my application. I've seen some articles about JNI but none seem to solve my issue.
If JNI or swig is not desired or seems too low level,
A really blunt approach is to wrap the .cpp in c/c++ program and built an .exe that dumps to stdout/file. Then execute that in java via an external shell command.
Another good alternative is
Apache thrift
This basicly handles everything and goes everywhere so to speak (works by auto-generating code to target languages) and it is one I usually recommend in RPC situations. However there could be more setup cost involved (in the end, depends on your actual needs) - also since you need to host the .cpp in a service, in your case, locally.
If you package your library inside a shared object or a dll, you can also use JNA: https://github.com/java-native-access/jna or https://github.com/java-native-access/jna/blob/master/www/GettingStarted.md
For example, you already have mapping to Windows API.
Another example is a mapping of mediainfo in Java: https://github.com/andersonkyle/mediainfo-java-api/blob/master/src/main/java/org/apothem/mediainfo/api/MediaInfo.java
Note that, as far as I understand it, this is based on JNI: it simplify the process since you mostly have to only declare interface on Java side and call appropriate method.
I am developing a Java application in which I need to call some C++ functions (from Google Talk library libjingle) . The objective is to run it all on Google App Engine (which only supports Python or Java).
How can I do this?
You need to define native methods in your java code for whatever you want to be implemented in C++ and directly access your native code. Then you run javah on your code and it will generate the C header files for you and you'll need to provide C++ implementations.
The native methods you can call from your Java code like any other methods and still they'll have their implementation written in C++ and talking to whatever other native library directly.
You then need to set the java.library.path system property to include the shared C/C++ libraries that you require: the google library and your own JNI implementation library would be required in this case.
If the library has C bindings through a DLL/SO, I usually prefer writing wrappers in Java using Java Native Access (JNA) rather than writing the bindings in C/C++ using the Java Native Interface (JNI). The former is easier to manipulate as the JNI access to Java objects is a real pain in the neck. However, it's not as obvious to wrap C++ classes using that API.
You might also want to look into the Simplified Wrapper and Interface Generator (SWIG) for automating part of this process!
You can't run native code on App Engine - only JRE code. If there's no avoiding the native code, you'll need to run this part of your app on another system, and call it from your App Engine app - or use the built-in XMPP API, in this case.
Is there a java api similar to RAPI? I want to be able to access files on the windows mobile device using a java desktop program.
Thanks.
You could use RAPI itself, and access it from Java using JNI or a wrapper like Swig
We were also looking for a similar API in Java but unfortunately none is available. I wrote my own RAPI wrapper using JNI and used that in my program.
The main problem with JNI is that any un-handled exceptions/faults cause the calling Java program to shutdown as well. Do keep that in mind when writing your wrapper. There are different approaches to safe guard these, the simplest and common approach is to write a standalone program written in .Net/C++ that communicates with the RAPI and your Java program communicates with that program using pipes/files etc. this way you also don't have to write a JNI wrapper :-)
I have a dll namely product.dll created using .NET. How can I access that dll's constructor or method using Java code.
Is it possible to access without using JNI?
You may take a look at jni4net which allows interoperability between the two. IKVM.NET is another alternative. Yet another option is to expose the functionality you have in the .NET library as a SOAP web service which is interoperable and could be consumed from a JAVA client.
There is a commercial product called JNBridgePro that will allow you to easily do this. You can even run the .NET dll inside the Java process if you like. (You can also run the Java and .NET in separate processes and communicate through sockets.) For more information, please see www.jnbridge.com, or contact us at the e-mail address on the Web site. (Yes, I am with JNBridge, but I felt that mentioning the product was appropriate in these circumstances.)