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
wrote:
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.
--
Paulo
