Anyone interested in embedding a JVM in their D app?

james via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Wed Jan 14 18:03:28 PST 2015


I think the goal of this may be backwards of what most people are 
thinking.

What I am trying for is not to write extensions to a java app in 
D through JNI.  Anyone is welcome to use any of this work to 
achieve that if they'd like.

The actual goal is to embed a JVM inside of a D program.  This is 
actually a practice from C++ that happens more than one would 
think.  This also makes several things easier as the D subsystem 
is correctly initialized.

There are several things that come with Java APIs only.  A few 
that come to mind are some database drivers (hsql recommends 
doing JNI from C++ to Java to use their driver).  Anyone familiar 
with hadoop, their remote file system driver is the same way (in 
older versions anyways).  They do provide a c library that does 
the embedding for you (so you may not of noticed).

There are other languages that do this to take advantage of the 
massive amount of DB support in java (last time I checked that's 
how DB drivers in R worked).

Anyone familiar with doing this from C or C++ knows it looks 
nothing like java though.

If you look at https://github.com/jamesmahler/djvm#example ... 
that's the equivalent of "System.out.println(100)" with the 
"cleaned up" api in djvm.

While using JNI inside a java app is messy... using JNI inside a 
C app is sometimes way easier.

Anyways, you are free to continue discussing trying to use D in 
Android.  I'd be willing to share any information and try to 
assist with that project as able.

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.
>
> 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.



More information about the Digitalmars-d-announce mailing list