On Wednesday, 14 January 2015 at 09:29:25 UTC, Russel Winder via Digitalmars-d-announce wrote:
On Wed, 2015-01-14 at 02:00 +0000, james via Digitalmars-d-announce
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 it
with djvm.d.

Whilst I have tinkered with JNI, I have never had to really use it in anger. And I, and many others, really want to keep it that way even though there are many who use it. It's like trying to program Python
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 that I
have never used it.

The current fashion is (or will be) JNR (which leads to JEP 191).

As far as I know JNA, JNR (and JEP 191) use JNI, more or less because
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 supposedly easy
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.


Reply via email to