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.

https://github.com/jamesmahler/djvm

There is an example usage in the README.md.  There's also why I'd
do such a thing in there.

I'm not sure if anyone else would be interested in this.  I'm
open to help and merge requests if anyone wants to join in.

In the short term, I still have several low level things to wrap
with the more D interfaces.

In the longer term, I want to have D interfaces around JDBC.

On 14/01/2015 3:00 p.m., james 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.
>
> https://github.com/jamesmahler/djvm
>
> There is an example usage in the README.md.  There's also why I'd
> do such a thing in there.
>
> I'm not sure if anyone else would be interested in this.  I'm
> open to help and merge requests if anyone wants to join in.
>
> In the short term, I still have several low level things to wrap
> with the more D interfaces.
>
> In the longer term, I want to have D interfaces around JDBC.

Definitely need to get JNI support first class.
It definitely will help with getting D on Android.

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.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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

On Wed, Jan 14, 2015 at 15:05:18 +1300, Rikki Cattermole via Digitalmars-d-announce wrote:
> Definitely need to get JNI support first class.
> It definitely will help with getting D on Android.

My experience is that the D runtime needed some work to accept that there are Linux machines without glibc (bionic for Android). After getting those assumptions out, I had it to a point where it was compiling, but things blew up in the runtime somewhere (or bionic; it was never really giving useful backtraces) during my argument parsing (my guess is the GC was mucking with the wrong bits, but there wasn't anything conclusive since debugging was never easier than what I got from logcat and looking at disassemblies). This was back in 2.065 era though and I haven't done much with it since then.

--Ben

On 2015-01-14 03:00, james 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.
>
> https://github.com/jamesmahler/djvm
>
> There is an example usage in the README.md.  There's also why I'd
> do such a thing in there.
>
> I'm not sure if anyone else would be interested in this.  I'm
> open to help and merge requests if anyone wants to join in.
>
> In the short term, I still have several low level things to wrap
> with the more D interfaces.
>
> In the longer term, I want to have D interfaces around JDBC.


Dropbox has a tool [1] for automatically generate the JNI glue code for connecting Java <-> C++. Perhaps it's possible to output D code instead.

[1] https://github.com/dropbox/djinni

-- 
/Jacob Carlborg

On 15/01/2015 3:26 a.m., Ben Boeckel via Digitalmars-d-announce wrote:
> On Wed, Jan 14, 2015 at 15:05:18 +1300, Rikki Cattermole via Digitalmars-d-announce wrote:
>> Definitely need to get JNI support first class.
>> It definitely will help with getting D on Android.
>
> My experience is that the D runtime needed some work to accept that
> there are Linux machines without glibc (bionic for Android). After
> getting those assumptions out, I had it to a point where it was
> compiling, but things blew up in the runtime somewhere (or bionic; it
> was never really giving useful backtraces) during my argument parsing
> (my guess is the GC was mucking with the wrong bits, but there wasn't
> anything conclusive since debugging was never easier than what I got
> from logcat and looking at disassemblies). This was back in 2.065 era
> though and I haven't done much with it since then.
>
> --Ben

That's trying to get JNI to work, I'm assuming that part has already been done and we want a nice wrapper around it.
At the worse case scenario, at least it'll work for e.g. Windows, OSX and Linux.

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.