dud: A dub replacement

[H. S. Teoh]

On Mon, Nov 25, 2019 at 07:48:46PM +0000, GreatSam4sure via Digitalmars-d-announce wrote:
[...]
> I am interested in D/java project. Can you help me with material or
> link on that. I Will be happy to use javafx as front end and D as back
> end for a desktop App.
> 
> I have looking on GraalVm but no luck yet. Just need a good tutorial
> for a start-up

So far, my only experience with interfacing Java with D is my Android
project, that involves Java code talking to Android's Java GUI APIs,
communicating with D code via JNI.

If you wish to go this route, I'd recommend reading up on JNI. The docs
are mostly geared for interfacing with C/C++ code, but it should be
relatively easy to interface with D code the same way.  You just need to
declare JNI methods in a D module so that D code can call it. Also, need
to be aware of JNI quirks to avoid runtime crashes.  With D's
compile-time introspection capabilities, I was able to come up with a
quite-nice wrapper for the JNI API, that saves a lot of typing (JNI is
notoriously verbose to setup per call across the JNI boundary).

In a nutshell, you declare native methods in your Java class(es), then
write a D module with appropriately-named functions according to JNI
naming convention, and compile that into an .so (or .lib), then use
System.loadLibrary() to load the methods at runtime, then call away.

This assumes the main program is started in Java, of course.  I haven't
tried doing it the other way (having main() in D, and calling Java from
there), but I imagine it'd be pretty similar: link with a JVM, and in
D's main() call whatever methods it takes to create the VM, then use JNI
to call Java methods in that VM instance.


Compiling a mixed-language project is a separate issue.  Dub is, sad to
say, of no help here. You're better off using something like CMake, or
something of that sort. I use SCons, but it's not as well-known and does
require a bit of an initial learning curve.


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher