Develop Reference

A platform for Java, Scala, Groovy and jRuby would be implemented in what language?

As an experiment I am working on a small platform for Java applications (client server, P2P etc.) which I would like to be able to use from both Java and Scala. And possibly also from Groovy, jRuby etc.
I know that Scala can call easily into Java, but that Java cannot as easily call back into Scala. I don't know how this is working in jRuby and Groovy.
My initial thought was to implement the platform in Java, and then see if I could make it available to other languages. However, the platform may include starting threads which call components that implement certain Java interfaces. Would it be possible to pass e.g. a factory implemented in Scala, but which implements a Java interface, to a Java component and have that Java component call the Scala factory?
What are your recommendations in general for implementing such a cross language platform?

I am by no means an expert and have never done such a cross-language project (just minor Java/Scala).
But I would suggest implementing it in the language:
you know best
makes you most productive
ensures the most maintainability
In my case it would be Scala.
So what I would do is define the API in the form of Java interfaces, which I would then implement in Scala (probably I would need to convert Scala/Java collections back-and-forth, but that would be an implementation detail).
That way you make sure that other JVM languages can interact with your API, and you implement it in whatever language you are best.

Java can call Scala as easy at the other way around,
With eclipse you need to install 'Scala IDE' from the 'eclipse market place'
and configure the compiler to 'Scala Then Java' option in Properties->'Scala Compiler'-> 'Build Manager'-> compileorder.
P.s. you also need to add Scala nature to the project.

Would it be possible to pass e.g. a factory implemented in Scala, but which implements a Java interface, to a Java component and have that Java component call the Scala factory?
Even if it were so, switching to Scala would not solve the problem, as then jRuby would have even more problems to access that component.
Actually, all listed languages declare interoperability with Java, but not with other languages. So first design goal is, your platform should be Java-compatible in all its API, though some components could be written in other languages - but so that it is cannot be seen by API users. The easiest way to make it so is to write all in Java. Besides, I recommend Java because features of "more advanced" languages has their reverse side - one innocent-looking line of code can consume enormous amounts of CPU time or memory.

Flexible jni project

It seems like that working with jni will become my everyday routine for a few months. Is there any some tools which simplify dealing with mixed Java + C++ projects?
Is it possible to re-generate glue *.h files and rebuild native libraries automatically? Or I should write some scripts for maven, ant, gradle, anything_else?
Is there any experience?

Check out JavaCPP! I also list other solutions on that page... There's also Jace that is useful when trying to use Java from C++.

Some months ago I faced the same questions. It seems that Java/C++ interop is reviving just now, and that you are one of the pioneers.
If you're merely using C++ objects from Java, JNA may be a better solution.
If you're using Java from C++, I didn't yet encounter a mature library. Although functionally quite complete, JNI is is a C api (intentionally, if you read the design rationale). If you are about to write lots of code for it, I think it'll pay to write a C++ framework around it that wraps the bare jobject ,jnienv, jclass... handles into explicit resources.
The real issues arise when the C++ and Java have to co-operate using callbacks etc... Buckle up if that's your intent...

You are asking about an experience. So my experience is, that you should start with very well designed requirements, behavior and objects lifecycle. That should result in a mature interface which will change very little in the future. The effect is that you will need to change the glue header files rarely and simple one shot javah is good enough. It all doesn't sound very agile i know, but then JNI is everything but a rapid development environment.
Changing the interface twice a day, adding and removing methods and changing signatures "just to see if it helps" is a sure road to hell. You are connecting two very different worlds in terms of memory management and JVM can get nervous very easily. Thread safety is yet another level up. The mentioned helper solutions, while they are undoubtely a clever piece of software, might give you a false perception that JNI is easy. Then JVM starts giving you exceptions out of nowhere, your objects will start geting uninitalized randomly, etc...

You can use SWIG to automatically generate glue code and have an make target to rebuild the native libraries. You can also use ANT's c++ task for the same purpose.

Is there a way to call the STL Libraries of C++ from Java using JNI?

Is there a way to call STL libraries from JNI, I believe JNI provides a C like interface for native calls, how do we achieve this for the C++ template libraries?

I agree that if you're looking for just the plain STL, you could probably use a Java library instead. However, if you insist on wrapping STL, SWIG provides some STL wrapping in JNI out of the box (see this for the basic mechanism), which should produce relatively stable, tested code.

I know this is possible, although I haven't done it myself. But JNI code can crash the JVM if you are not VERY CAREFUL. Also, JNI code is much more difficult to maintain than Java code. I was on one project where the Java -> JNI -> STL and COM code was thrown away and we replaced it with C# accessing the same STL and COM and a socket. We never looked back.
If you are doing only a small amount of JNI, it may be worth it. If you are creating a large interface via JNI, I strongly recommend instead writing the component that interacts with STL in C# instead of Java, and using a socket to communicate between the C# and Java components. It will be far easier to write, test, and maintain.

I have to ask why you find it necessary to use the STL libraries from Java. Is there something in them that's not provided by Java's own massive set of libraries?
I understand why you'd have to call your own code (and I'm assuming you've profiled the Java code and found it wanting, otherwise your effort is wasted) but you seem to be asking how to call STL stuff directly.
We've often had trouble with JNI and it makes our code less portable, so you have to have a very good reason for wanting to use it in our shop, and you have to prove with hard data, why the Java-supplied stuff is not adequate.

Yes. You required to use the swig typemap to convert C++ STL classes to Java objects... and vice versa.
For more information, please visit,
http://www.swig.org/Doc2.0/Android.html

Accessing .NET/dll libraries/components from Java?

Are there inexpensive or free gateways from .NET to Java? I'm looking at some data acquisition hardware which has drivers for C/C++ and .NET -- I really don't want to do any programming in .NET.
Update: I haven't done what I originally wanted to do, but I've done something similar, using JNA to encapsulate some functions from a DLL, in order to control a USB hardware device from Java. (the DLL comes from the device manufacturer) It works really nicely. Thanks!

You could also try to use JNA for accessing the native library. JNA provides Java programs easy access to native shared libraries (DLLs on Windows) without writing anything but Java code—no JNI or native code is required. If their API is fairly straight foward, this might be the path of least resistance.
See their getting started guide where they call some native code (printf and GetSystemTime).

Well, there's JNBridge and EZ JCom, just from a Google search.
You could also use IKVM which is a slightly different approach.
(Any reason for not wanting to learn .NET, out of interest? It's a nice platform, and C# is a lovely language...)

If they have C++ versions of the drivers then you could write a wrapper around it using JNI and then load that in Java. JNI can be a bit of a pain, but it would let you use the C++ version of their drivers and not have to deal with .Net at all if you don't want.

I am partial to the recommendation to jump in the deep end with C# since it is so similar to Java. I did this and used IKVM to compile my favorite Java libs. to .NET assemblies and you get [nearly] all the core java runtime classes to boot, so if you tire of trying to find just the right C# collection type, you can always go back to java.util. (No generic collections though. Not sure why.)
Depending on what platform you're on, you have several choices for free IDEs too. For windows you can get Visual Studio Express for free but I also use SharpDevelop. You can also get the Mono IDE on Linux (and a few flavours of Unix, I think ?).
The C# learning curve is shallow if you already know Java. I only blew off 1.5 limbs on landmines that came out of nowhere for reasons I still don't understand, but workarounds were easy to come by. The worst thing about it was the darn developer docs which are AWFUL on account of being so slow. I really miss the snappiness of JavaDoc. Not only are the online docs incredibly slow, the problem is compounded by someones's iffy decision to put class summaries, constructors and methods/properties all on seperate pages so it just takes forever. Someone said to get the docs installer and install docs locally for a slightly improved experience. Not a bad idea I suppose.

I am author of jni4net, open source interprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. I hope it will help you.

If you have a Java application, the JNI mentioned by the others will be the way to go. You write some wrapper classes, and that's it.
If writing the wrappes is a too big task (depending on the number of methods you have to wrap), have a look at SWIG . I think it generates wrappers automatically, but I never actually used it.
If you want to code in the Java language, but you don't care if your program will run on the JRE/JVM, then you might as well use Microsoft J#. Basically, it's writing Java-Code wich is compiled to .NET-Bytecode and can use the .NET classes of the driver as well as your existing Java classes. With J# you will run into problems if your existing Java-code is newer than Java 1.4, look at this question on how to solve them.
From that point on, you could later add code in J#, C# or any other .NET language. However, you won't get back to the JRE/JVM easily.

Wrapping up a C++ API in Java or .NET

Has anyone successfully "wrapped up" a C++ API in Java or .NET? I have an application that provides a C++ API for writing plug-ins. What I'd like to do is access that API from .NET or Java.
Would I need to use COM, or are there simpler/better alternatives?

If you have a very straight forward method signatures (i.e. methods that takes and returns primitive types such as int, char[], void* ... etc), it is reasonably easy to do so in .NET and still possible but a bit harder in Java with JNI.
However, if your class methods uses modern C++ programming techniques such as boost shared pointers and STL containers then it is a very different story. You will need to be really careful with memory management in this case.
EDIT:
It is gonna be even more interesting if the method has C++ template arguments because C++ template system is very different from C# or Java generics in that it is only a compile time mechanism. Basically this means the signature of the method or class is different every time you pass a different data type to the template argument. This made the method impossible to wrap in C# or Java.

I think that you may be asking to something similar to the Java Native Inferface It allows you to call code written in languages such as C++. I've never worked with it though. But you may want to check it out. Hope it helps.

On the Java side there are many options here .. this question actually is fairly close to what you are looking for provided your API can be boxed in a DLL, com or activex objects.
I personnaly used JIntegra to wrap API calls to office (Word) and used it directly witin Java. It did take some hacking to get the desired functionnality but we ended up making it work. The fidling was actually on the Word side, the actual integration was relatively easy.

If you are going to use .NET, I would recommend creating a C++/CLI wrapper. C++/CLI lets you mix the managed .NET code with native C++ code. There are some tricks to this approach, but it works very well in majority of cases.
Wikipedia entry has also some good links.

Using SWIG to handle the JNI stuff makes wrapping a cpp API and using it from Java quite painless.
Here's a SWIG tutorial

I'm the lead author on SlimDX. It may not be the largest open source interoperability project out there, but at 150K+ lines across the project, it's fairly substantial. It's written using C++/CLI, which is a Microsoft developed language, largely compatible with C++, that is designed to allow you to build wrappers. It works very well, with the caveat that it is Windows only. Mono will not take it. I don't know how much of a concern that is for you, but it's probably a better alternative than COM. Unfortunately there's a lot of tips and tricks that you have to basically come up with yourself. I've meant to blog about a lot of the ones we use on SlimDX, but somehow I never quite get around to it.
On the Java side, I believe you have to use JNI. Good luck with that. I've never talked to anyone who's worked with JNI without both of us laughing at it, in a bad "ouch that hurt" sort of way.

I maintain software that is implemented in C++ but must have interfaces in multiple languages including Java and .NET, but also including delphi and VB6. Plus, it has to work on multiple platforms (so Java needs to work on unix).
The way it was done was to use a single DLL exporting plain C functions using primitive types. For example, given an class Foo:
long MY_EXPORT_FLAG FooCreate()
{
return (long)new Foo();
}
void MY_EXPORT_FLAG FooDestroy(long Handle)
{
delete (Foo*)Handle;
}
void MY_EXPORT_FLAG BarMethod(long Handle, const char* pStr1, long* pReturnValue)
{
*pReturnValue = ((Foo*)Handle)->BarMethod( pStr1 );
}
Then your JNI/.NET/VB6/Delphi code implements language specific class wrappers, but call these C dll functions. Each class wrapper would contain a Handle, and pass it into the C functions.
This works quite well because most languages tend to use C as the lowest common denominator, so as long as you can export your interfaces through a thin C api you can build interfaces for other languages.
We export a C (and not C++) api in the DLL because function signatures are much more standardized across platforms.
Don't forget, that on C# and Java, you'll have to deal with multibyte string encoding, so you should figure out how to transcode your strings to/from your C++ code. This typically involves knowing about locales, or you can cheap out and just support UTF-8.