Anyone interested in embedding a JVM in their D app?

[Paulo Pinto via Digitalmars-d-announce]

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