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'm trying to write a plugin for a Java Application. The plugin should be able to tell the Java Application that new events have been recognized (Observer Design Pattern, Polling ... thats not the point). The problem is that the events are tracked gestures coming from a Microsoft Kinect controller (I´m using C++ and the Microsoft Kinect SDK because I have to). So that means I have to communicate between the Java Application and my Kinect Application.
I thought of something like an adapter design pattern where the Java application is "including" the interface (c++ header file, dll etc.). First I thought of JNI but then I have to write a DLL that will be used on both application sides, right? Another thing I thought of was to provide the gesture data via a protocol like UDP (or something more lightweight?). The last thing I heard of was to write a COM+ assembly ... but to be honest my knowledge about COM+ is rather little.
JAVA APPLICATION << ----- ??? ----- >> KINECT APPLICATION
May be you should have a look at google's Protocol Buffers.
Since you are considering JNI.
I'd suggest you refer to this IBM tutorial.
JNI allows the java application to call c/c++ methods and vice-versa.
Also have a look at this
question, if you are calling java from c++.
I have found some examples such as here, here and here which recommend you either used a shared memory structure or else use sockets.
I think that in this case, letting your programs communicate through sockets would be the best idea since your applications will not be that tightly coupled, so you just need to expose an IP, a port and a set of commands.
According to this it seems possible to create a C++ server on the Kinect, but other than that I can't say much since I have never worked on Kinect related projects.
JNI (Java Native Interface) allows the java application to call c/c++
methods.
All this requires that we have a means of communicating (Integrating Java
with C++) between Java and C++. This is provided by the JNI (Java Native
Interface).
For a practical example of using the JNI and calling native methods from Java, see this InfoWorld article.
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.)
I'm supporting a large system written in C++ and we now have a requirement for our application to talk with a third party system which only provides a JTAPI interface. It would appear that I am stuck writing a JTAPI proxy in Java that talks JTAPI on one side and some more language-neutral API on the other. However, this feels like it should be a solved problem and I don't want to unnecessarily re-invent the wheel. What is the best solution to interface to JTAPI from C++? Does such a proxy already exist, or perhaps is there a solution that does not require a Java layer?
This article shows a way to call Java objects from C++.
You can also think of embedding the JVM in your C++ program. This page talks about a possible way to do this. Also see: Embed Java code into your native apps
If your C++ system provides an API, then the easier approach is to write a Java program that wraps the C++ API (using JNI) and call the JTAPI library from there.
I have a really simple Java class that effectively decorates a Map with input validation, with the obvious void set() and String get() methods.
I'd like to be able to effectively call those methods and handle return values and exceptions from outside the JVM, but still on the same machine Update: the caller I have in mind is not another JVM; thanks #Dave Ray
My implementation considerations are typical
performance
ease of implementation and maintenance (simplicity?)
reliability
flexibility (i.e. can I call from a remote machine, etc.)
Is there a 'right way?' If not, what are my options, and what are the pro/cons for each?
(Stuff people have actually done and can provide real-life feedback on would be great!)
Ok. Here's another try now that I know the client is not Java. Since you want out-of-process access and possibly remote machine access, I don't think JNI is what you want since that's strictly in-process (and a total hassle). Here are some other options:
Raw Sockets : just set up a listener socket in Java and accept connections. When you get a connection read the request and send back a response. Almost every language can use sockets so this is a pretty universal solution. However, you'll have to define your own marshalling scheme, parsing, etc.
XML-RPC : this isn't as hip these days, but it's simple and effective. There are Java libraries as well as libraries in most other languages.
CORBA : as mentioned above, CORBA is an option, but it's pretty complicated and experts are getting harder to come by.
Web Server : set up an embedded web server in your app and handle reqests. I've heard good things about Jetty or you can use the one provided with Java. I've used the latter successfully to server KML files to Google Earth from a simulation written in Java. Most other languages have libraries for making HTTP requests. How you encode the data (XML, text, etc) is up to you.
Web Services : This would be more complicated I think, but you could use JAX-WS to expose you objects as web services. NetBeans has pretty nice tools for building Web Services, but this may be overkill.
Will you be calling from another JVM-based system, or is the client language arbitrary? If you're calling from another JVM, one of the simplest approaches is to expose your object as an MBean through JMX. The canonical Hello World MBean is shown here. The pros are:
Really easy to implement
Really easy to call from other JVMs
Support for remote machines
jconsole allows you to manually test your MBean without writing a client
Cons:
Client has to be on a JVM (I think)
Not great for more complicated data structures and interactions. For example, I don't think an MBean can return a reference to another MBean. It will serialize and return a copy.
Since your callers are not Java apps and you're already foreseeing networked callers, RMI-IIOP (CORBA) might be an option. Though it's definitely not easy to implement, it has the advantage of being a widely-recognized standard.
Since your caller is not JVM-based, this is a question of inter-process communication with JVM. The options I have in mind are:
Communicate over a socket: make your JVM listen to incoming connections and caller send commands
Communicate using shared files (caller writes to file, JVM polls and updates)
Using JNI, start JVM inside a callers process and then use RMI/MBeans to communicate with the first ("server") JVM. Caller will have access to results using JNI
Option 3 IMO is the most "Java" way of doing this, and is the most complex/error-prone.
Option 2 is ugly but simple
Option 1 is moderately easy (java part) and otherwise ok.
For ease of use, I would use Spring Remoting. If you are already using Spring in your project, that's a no brainer. If you arent ... well you should have a look anyway.
Spring provides an abstraction that allow you to switch remoting protocols easily. It supports the most widely deployed protocols (SOAP, Hessian, Burlap, RMI, ...). If you are calling from non Java code, Hessian has support in a number of other languages, is known to be more efficient than SOAP and easier than CORBA.
Beanshell is a shell-like java interpreter that can be exposed over a network socket. Basically you do this from java:
i = new bsh.Interpreter();
i.set( "myapp", this ); // Provide a reference to your app
i.eval("server(7000)");
and then you do this from anywhere else:
telnet localhost 7001
myapp.someMethod();
This little utility does remote java invocations much more easily than JNI or RMI ever has.
For more, start at: http://www.beanshell.org/manual/remotemode.html
JNI (Java Native Interface) allows access to java code from C or C++.
I have an Inno Setup script (installing a Java program) which calls some Java methods to perform some operations or check some conditions.
I (actually my predecessor) just instanciate java.exe on each call. Which is, obviously, costly, although not critical in my case (and the Windows cache kicks in, I suppose).
An alternative is to use some inter-language communication/messaging, your Java program acting as a server. Corba comes to mind, as it is language agnostic. But a bit heavy, perhaps. You can use sockets. RPC is another buzzword too, but I haven't much experience in the field.
What you want is the Java Native Interface (JNI), despite the difficulties that it may present. There is no other equivalent technology that will be as easy to implement.
As mentioned in the comments for the preceding answer, the JNI is optimized for calling native code from Java, but it can also be used for the reverse with a little work. In your native code you'll need to implement the JNI entry point--something like SetMapPointer()--then call that function from the Java code once the Map is built. The implementation of SetMapPointer() should save the Java object pointer someplace accessible, then the native code can invoke Java methods on it as needed.
You'll need to make sure that this happens in the right order (i.e. the native code doesn't try to access the Map before it's been built and passed to native code), but that shouldn't be an especially hard problem.
Another alternative to consider if the other process will be on the same machine and the OS is POSIX-compliant (not Windows) is Named Pipes.
The outside process writes the operations, as strings or some other agreed-upon byte encoding, to the named pipe while the Java application is reading from the pipe, parsing up the incoming operations and executing them against your object.
This is the same strategy that you would use for socket connections, just instead of a SocketInputStream you'd be reading from a FileInputStream that is attached to a named pipe.
An alternative to CORBA is ICE, unless the licence is a problem (it's GPL, but you can also buy a commercial licence).
It has pretty much all the benefits of CORBA, but ZeroC, the vendor, provides bindings for many different languages. CORBA vendors tend to only provide one or two language bindings, and then you start finding compatibility problems.
The documentation is also excellent. I wouldn't have said it was particularly easy to pick up, but probably easier than CORBA.
Otherwise, another option I don't think has been mentioned is the new middleware/RPC framework developed by Cisco, now donated to Apache, called Etch. It's still pretty new though, and documentation is sparse.