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