digitalmars.D.announce - Anyone interested in embedding a JVM in their D app?
- james (11/11) Jan 13 2015 I've been playing with jni.h and D. I think I've got a fully
- Rikki Cattermole (3/14) Jan 13 2015 Definitely need to get JNI support first class.
- Ben Boeckel via Digitalmars-d-announce (11/13) Jan 14 2015 My experience is that the D runtime needed some work to accept that
- Rikki Cattermole (5/18) Jan 14 2015 That's trying to get JNI to work, I'm assuming that part has already
- Russel Winder via Digitalmars-d-announce (23/27) Jan 14 2015 Whilst I have tinkered with JNI, I have never had to really use it in
- Paulo Pinto (14/40) Jan 14 2015 Performance is good enough if you do the same approach as remote
- james (30/56) Jan 14 2015 I think the goal of this may be backwards of what most people are
- Jacob Carlborg (6/17) Jan 14 2015 Dropbox has a tool [1] for automatically generate the JNI glue code for
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.
Jan 13 2015
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.
Jan 13 2015
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
Jan 14 2015
Rikki Cattermole <alphaglosined gmail.com> 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: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.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
Jan 14 2015
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. =20Whilst 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. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Jan 14 2015
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:Performance is good enough if you do the same approach as remote method invocation, by using a single call and not multiple ones.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.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
Jan 14 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.
Jan 14 2015
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
Jan 14 2015