On Wednesday, 14 January 2015 at 09:29:25 UTC, Russel Winder via
On Wed, 2015-01-14 at 02:00 +0000, james via
I've been playing with jni.h and D. I think I've got a fully
working jni.d and I have the start of a nicer D wrapper around
Whilst I have tinkered with JNI, I have never had to really use
anger. And I, and many others, really want to keep it that way
though there are many who use it. It's like trying to program
from C, only worse performance.
Performance is good enough if you do the same approach as remote
method invocation, by using a single call and not multiple ones.
There is JNA of course, which does some similar stuff, many use
have never used it.
The current fashion is (or will be) JNR (which leads to JEP
As far as I know JNA, JNR (and JEP 191) use JNI, more or less
they have to. The issue is to make using the adaptor as easy as
possible. JNI is not easy; JNA is easy but slow; JNR is
and fast, so hopefully JEP 191 will be.
JNI is hard on purpose. Mark Reinhold has said during the JavaONE
2014 that it was made so, to force Java developers to stay away
from writing unsafe code, specially given Java's portability goal.
Now with Java being adopted left and right for HPT and big data,
that is an hindrance for integrating legacy code, hence the need
for JNR, born out of JRuby project.
Interesting enough, something like JNR was one of Microsoft
extensions to Java and the precursor of .NET P/Invoke.