I am trying to include a computational chemistry/physics visualizer known as Avogadro (1) inside of my jTabbedPane project. I used QT Jambi (1) to create a JUI (Java GUI) out of Avogadro's UI in Eclipse. I was successful in that attempt, but the GUI was (obviously functionless) upon running.
In short, the complication here is me trying to access the C++ libraries of a massive project that only has the ability to compile with CMake (Importing into Eclipse was not successful). To make it a bit worse, all I believe I need to interface with is a .cpp file that regulates the GUI and links it to the rest of the project, thus providing functionality. I plan to use SWIG to interface with the functions in the aforementioned cpp file and I plan for the interface to work with the C++ library to add functionality to the Java GUI.
Any thoughts on how I could do this? Do I need to SWIG the entire project?
It looks like Avogadro is open source. Therefore, you can download the source code and SWIG the entire project. This will give you the same classes in Java as you would have in C++.
If you only want a subset of Avogadro's functionality, I would suggest creating a simple bridge class in C++. This bridge class, with possibly other helper classes, could then be SWIGed. Your Java would now use the bridge class to execute the Avogadro library.
Related
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 not a Java developer, but I need to solve a problem: I need to include linux SO library to an existing Java project. The library is developed using CGO and works fine with C++, Python ctypes, Ruby FFI and so on. But I can not include it to Java project without of errors (java.lang.UnsatisfiedLinkError). I have read some articles like this, and the described method is that I need use javah to create a C header first, and then write a C program, and so on. But what to do, if I have already compiled *.SO file?
Is there a way, how to simply load an existing SO file (written on C) and call it`s functions?
Java doesn't have builtin FFI functionality.
One option for using native libraries (.dll/.so) with Java is to write a JNI wrapper library that has special functions that can be bound to Java native methods. That's the option where you need to use javah to create a header file for the wrapper library. See the "Java Native Interface" documentation on Oracle's site for how to do that.
The other approach is to use a "glue" library like JNA. You don't need to build another library this way but you need to include JNA in your project and do the necessary Java declarations for it. You can find the documentation for JNA in the Github repository together with the code. That approach is similar to what Python, Ruby, etc. are doing.
I recommend reading up on both to see what will better suit your needs.
I have a compiler for a domain specific language that outputs a .net dll (that can then be used to do whatever the DSL said it should). It works well under .net but now I need to make the compiled dll functionality accessible from Java. The interface changes depending on the DSL, much like it would if I was implementing an F# type provider.
Ideally, I would like something along the lines of Reflection.Emit except that it would generate Java bytecode. It is important that the end-user can debug their Java code that uses my generated library from a Java GUI, so I don't think I can just use IKVM to instead include the Java code in .net. I also cannot use a commercial product such as JNBridge because all the users would need to install it, and call it every time their DSL code changes.
Is there a better solution than generating a .java file in text format and compiling it with a Java compiler? The .java file would just be a light-weight interface talking to the .net dll over some IPC mechanism (perhaps a named pipe), and its purpose would be to provide a typesafe interface similar to what would be seen from a .net application (except with indexers, getters, setters, overloads, etc replaced with some sort of horribly verbose syntax). Many thanks.
Java native interface is a way to call native code from Java (That dll isn't running on the JVM, thats for sure). Throw your dreams of "Write once run anywhere" in the bin now.
If you want to use dlls then you have to use JNI (or something similar or based on JNI like jni4net). It's not as pleasant as say, using c++ from c#, but it's pretty doable and far and away the best way to use dlls from java (I think the second best is re-writing the native code).
Alternatively you could run a windows process alongside your java app and soap/json/namedpipes/etc between the two, is that what you suggest in the last paragraph?
This would be odd for a small solution, but for a larger modular project it's not so crazy. I would recommend using sockets to communicate between the two, because I think sockets are easiest. It says client/server in the example, but it could be two processes (java and f#). ... This causes problems for performance, synchronisation, firewalls etc.. ahhh, just use JNI.
I have a third-party DLL, which consists of fairly a big number of interrelated classes (maybe written in C++) , the Java Native Access package wants the programmer to write an interface for each and every class within the DLL, In VB.net the Object Explorer makes life a piece of cake; however, in java i couldn't find such a tool.
Are there any tools that takes the DLL file and generate all needed JNA interfaces ?
Best Regards
JNAerator can "compile" native headers in order to generate JNA mappings, with some limited C++ support.
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.