views:

257

answers:

8

Background: We are designing a physics app, that will do a lot of data analysis, but our focus is integrating physical electronic equipement.

Basically I would like to be able to call root (it's a big data analysis library from CERN written in C++) library written in C++ library from Java. Basically ability to use ROOT classes from Java (and doing it without losing much time to code JNI wrappers) is a showstopper to us (if it will be hard, most probably we will be using Qt).

I can think of following methods

  • JNI - as I said - we dont want to write wrappers for every class. . .
  • JNA - JNA doesnt provide C++ mappings, but only C.
  • SWIG - I didn't use it, but heard it's hard to use.

Other things that may be revelant: we have access to root source code, but we dont want to change it. We want results to be portable. We would like to stick to free libraries. And as I said - we would be able to use much of the ROOT code from the beginning, without fuss.

+1  A: 

With any choice, you're going to need to do some wrapping. While you don't want to write JNI wrappers for every class, you could write higher level C++ classes that encompass groups of methods. Then you only need to write wrappers for the higher level classes (this approach works for other methods too, not just JNI).

Jeff Storey
I thought about it. have some C interface that takes and returns arrays and wraps many C++ calls (and creates/destroys objects).
jb
why does it it need to be C and not C++?
Jeff Storey
I really hate writing C/C++ code, and if I use C interface, I'll be able to use JNA to connect to C lib (and using JNA means no C code :))
jb
A: 

Just a thought but can you use Python since Root already supports it? You might well become reasonably proficient in the time it would take to wrap the code for Java.

Duck
Well it occoured to me when I found python root bindings in my ubuntu repo. If I will have choice -- Qt or Python I'll choose python. But I'll stick to java (and maybe learn python during some small project).
jb
A: 

Consider using C# instead of Java. If you're already familiar with java, switching to C# is easy and it has much better support for invoking native code.

Wim Coenen
C# is not so platform agnostic. We choose Java because some other features (apart from that we have some java experts;) for example we like dynamic linking (it allows us to include plugins in very easy way).
jb
Mono is a cross-platform implementation of the C# compiler and the .NET framework. And AFAIK, the C# features are a superset of java (except for checked exceptions). Plugin architectures in C# work much as under java (define plugin interface, load and instantiate plugin through reflection)
Wim Coenen
A: 

Whenever you call C or C++ code from Java via JNI or equivalent, you run the risk of destabilizing the Java platform due to issues with memory management and/or thread safety on the C/C++ side.

Before going down the JNI, etc route, I think you should consider other alternatives:

  • Take Java out of the equation and implement entirely in C++ (or C++ / CC# as someone else suggested).
  • Create a C++ command-line application that does the task that you need to do using the native library, and run the application using one of the java.lang.Runtime.exec methods.
  • Create a "server" wrapper in C++ for the library that exposes the functionality that you need as a custom protocol, and code the Java side to talk to the server using HTTP, raw Sockets, Pipes, or whatever transport level is appropriate.

The alternatives all have downsides, but so do JNI / JNA and the like; see the first paragraph.

EDIT: when you make the decision to use JNI / JNA in a system, there are likely to be long term consequences. In addition to the stability issue, you have to consider portability (will the native library work on Windows, Linux, etc), build issues (it is hard to build native libraries in Ant, etc), platform versions issues (will upgrading to Java 7 break something?), developer skills ("Joe" who did the JNI integration has left - who else knows Java, C++ and JNI?). The sum of these issues is (IMO) more significant than the time needed to do the initial development.

Stephen C
Could you elaborate on thread safety issues, know about possible memory management issues, but what about thread safety?
jb
A: 

What about writing the classes/functions you need in C++, compiling, and calling exec() on them from java?

Peter
A: 

if it will be hard, most probably we will be using Qt

Why don't you focus on that? So far you have not mentioned any reasons why Java should be preferred.

If the biggest part is the ROOT source and the code that calls it you will be probably much faster doing it all in C++.
As you are ok with Qt, the UI shouldn't be much to worry about.

edit:
I can't really see any advantages to the Java-approach - you have to port a big part of the source to other platforms anyway, you add in complexity with the wrapping layer and you have more dependencies.

Georg Fritzsche
No, we are not OK with Qt ;), but we could learn :). We want to have plugin architecture, and I don't know how to do it well in C++, In java you just drop plugin jars into lib directory, voila classes are aviable to your app. Also having one binary version for all the sistems is quite nice.
jb
But you still have to build ROOT and all the wrapping code for each platform, thats why i don't see the advantage.Qt btw gives you a plugin framework: http://doc.trolltech.com/4.5/plugins-howto.html
Georg Fritzsche
Thanks for info on plugin framework.
jb
+4  A: 

Write a small C++ application which reads in your input from stdin and writes an output to stdout. Then run the process from within your java app and read the output from stdout.

This is the best way to do it without JNI (and it is pretty easy to do)

Johnny Boy
+1 for the thinking-out-of-the-box answer.
MP24
+1  A: 

JNIEasy supports mapping of C++ classes to Java POJO classes but it costs 399€. Since you prefer free libraries you might want to look for solutions that use something like CORBA. It is the only way to have C++ classes mapped to Java classes.

EDIT: Have you considered JAS3, it is a java library similar to root?

tulskiy
Thanks for the JAS3 link. The problem is that nonprogrammer physicists want ROOT. But I will try to convince them that root is non essential, and thought it might be used via JNI.
jb