On Tue, Dec 17, 2019 at 10:25:26AM -0800, H. S. Teoh wrote: [...]
> 	http://dpldocs.info/this-week-in-d/Blog.Posted_2019_12_09.html
[...]

And I might add, that since that blog was posted there has been significant progress. Runtime initialization is now working, and you can create a Java VM and use that too (though in Android's case this is not necessary or desirable, since JNI docs say that currently only one JVM per process is supported).

Remaining issues (that I'm aware of) are:
- Support non-final classes on D side;
- Method overloading;
- Using `scope` to handle lifetime issues (maybe?).

Other than that, it's seriously awesome stuff that anyone who has an interest in Java/D interop should check out.


T

-- 
Nobody is perfect.  I am Nobody. -- pepoluan, GKC forum

On Monday, 16 December 2019 at 21:37:51 UTC, Adam D. Ruppe wrote:
> I'm gonna drop the link here without further comment:
>
> https://github.com/adamdruppe/d_android
>
> hopefully I've written enough in the repo so anyone who wants to play with it can... and if not, I need to fix the docs :)
>
> let me know if you find any success or failure playing with it.

Nice work!

On Monday, 16 December 2019 at 21:37:51 UTC, Adam D. Ruppe wrote:
> I'm gonna drop the link here without further comment:
>
> https://github.com/adamdruppe/d_android
>
> hopefully I've written enough in the repo so anyone who wants to play with it can... and if not, I need to fix the docs :)
>
> let me know if you find any success or failure playing with it.

👇️

> Download the Android NDK. I have version 20 here, I believe it will work with >anything past version 18. Set the environment variable NDK to its path.

> Download LDC, at least version 1.19. Make sure ldc2 is in your PATH.
>If you use dub, make sure you have at least version 1.18
>Build the runtime with ldc-build-runtime for each supported platform. See the android-setup.d for my notes. You can't run that program yet but you can easily follow along with the short, simple comments. It expects these results will be found in this same directory.

>Build your program for each supported platform. My android-dub-build can help with this.

>Copy the generated libs into your existing Android project's jniLibs folder. >My android-dub-build will do this for you too if you pass it the directory.


This part is unclear to follow

On Tuesday, 17 December 2019 at 18:29:32 UTC, H. S. Teoh wrote:
> Remaining issues (that I'm aware of) are:

I also haven't finished supporting all the various Java arguments. Notably arrays are unimplemented right now as well as handling interfaces (if a D function takes a CharSequence but the Java user passes a String, that should work, but doesn't yet. Probably a case of calling IsInstanceOf a few times, and I also haven't determined how to determine an object that implements multiple interfaces right now - the D thing right now makes a magic base class so can't do that twice. Will probably look like class Foo : JavaObject!("package.name", Foo, IWhatever, BaseClass).)

And my stretch goal of extending a Java class in D :P

I also haven't yet implemented thread support. A static ctor can do it but I'm actually concerned that is a bit too magical. I need to experiment more before just diving in.

On Tuesday, 17 December 2019 at 20:26:39 UTC, aberba wrote:
> This part is unclear to follow

OK, I'll rewrite it with more examples later in the week. It is still a little bit of a pain to set up too so if I can fix that, the instructions will be simplified as well.

On Tuesday, 17 December 2019 at 20:47:24 UTC, Adam D. Ruppe wrote:
> On Tuesday, 17 December 2019 at 20:26:39 UTC, aberba wrote:
>> This part is unclear to follow
>
> OK, I'll rewrite it with more examples later in the week. It is still a little bit of a pain to set up too so if I can fix that, the instructions will be simplified as well.

Maybe Docker can help ease the burden for others to test it.

On Tuesday, 17 December 2019 at 18:08:07 UTC, jmh530 wrote:
> On Tuesday, 17 December 2019 at 17:41:46 UTC, bachmeier wrote:
>> I had no idea that existed. That should really be promoted. There might be a lot of interest.
>
> First commit was only 8 days ago [1]. I'm sure there will be a bigger announcement when it's ready.

If I announce lol

but yeah, I just started this a couple weeks ago. The thing that delayed me on the android project was the android build system and IDE, it took me FOREVER to figure out just how to get my code actually running there. (That's why I'm trying to simplify it to just running `android-dub-build path/to/android/studio/project` for the future).

Then I got to actually look at the interop and my original goal was simply to forward the JNI stuff to a regular D function more easily.... then I realized jni lets you do so so so much more and I went a little nuts.

What you see in there already is kinda incredible: you can `auto a = new SomeObjectFromJava();` and it... works. When I started, not in my wildest dreams did I expect to actually have a natural constructor for the foreign language object but here we have it.

So pretty cool stuff. Though I can't make any promises about performance and debugability. I'm gonna try to do load-time checks of signatures and I expect that will help, and speed relies on how JNI does it and idk how much that is (though things like using `wstrings` slicing the chars should help, it is still possibly an arbitrary translation layer) but it is still probably not going to be amazing; the IDE will just see it as an opaque blob I think.

but my jni experiments have so far pleasantly surprised me, so maybe it will again.

On Tuesday, 17 December 2019 at 20:57:54 UTC, bachmeier wrote:
> Maybe Docker can help ease the burden for others to test it.

oh it isn't that hard... as of now the trickiest thing is the druntime build and ldc comes with a script to help with that. The script just worked on my box for x86, arm64, and x86_64. You also need the android stuff from Google but that's I think to be expected for the domain... and in theory we could skip that but in practice the goal of this is to interop with existing company workflows so I expect they will already be using it anyway.

The other arm runtime did NOT work with the script, but conveniently, ldc offers a binary download of that on their releases page! So just download it, rename the directory and put it in the right place, and you're good to go.

But aside from that downloading, otherwise you basically just run the program.

On Tuesday, 17 December 2019 at 21:08:07 UTC, Adam D. Ruppe wrote:
> On Tuesday, 17 December 2019 at 20:57:54 UTC, bachmeier wrote:
>> Maybe Docker can help ease the burden for others to test it.
>
> oh it isn't that hard... as of now the trickiest thing is the druntime build and ldc comes with a script to help with that. The script just worked on my box for x86, arm64, and x86_64. [...]
> The other arm runtime did NOT work with the script, but conveniently, ldc offers a binary download of that on their releases page! So just download it, rename the directory and put it in the right place, and you're good to go.

LDC 1.19 final will probably come with a native Android/AArch64 package. It's going to contain prebuilt Android/x86_64 druntime/Phobos too, and the armv7a package will contain the i686 libs; i.e., there'll be prebuilt libs for all 4 Android platforms. See https://github.com/ldc-developers/ldc/pull/3244; I'm just waiting for LLVM 9.0.1 final to be released (planned for Dec 19th).

Instead of wrappers around ldc2 and dub, I'd prefer a little generic tool, something like ldc-build-runtime, which automates

1) downloading a prebuilt LDC package for a specified cross-compilation target,
2) extracting & renaming the libs,
3) extending ldc2.conf by an appropriate section

Step 3 includes selecting a C cross-linker for most targets and could be simplified to just specifying the NDK path for Android targets.

Usage would be something like:

$ ldc-add-target android-aarch64
Enter path to Android NDK: /path/to/android-ndk-r20b
$ ldc2 -mtriple=aarch64-linux-android ...
...
$ ldc-add-target windows-x64
$ dub --arch=x86_64-windows-msvc ...

The tool could also create little forwarding scripts (aarch64-linux-android-ldc2).

On Tue, Dec 17, 2019 at 10:28:32PM +0000, kinke via Digitalmars-d-announce wrote: [...]
> LDC 1.19 final will probably come with a native Android/AArch64 package.  It's going to contain prebuilt Android/x86_64 druntime/Phobos too, and the armv7a package will contain the i686 libs; i.e., there'll be prebuilt libs for all 4 Android platforms. See https://github.com/ldc-developers/ldc/pull/3244; I'm just waiting for LLVM 9.0.1 final to be released (planned for Dec 19th).

Awesome!!


> Instead of wrappers around ldc2 and dub, I'd prefer a little generic tool, something like ldc-build-runtime, which automates
> 
> 1) downloading a prebuilt LDC package for a specified
> cross-compilation target,
> 2) extracting & renaming the libs,
> 3) extending ldc2.conf by an appropriate section

Yeah, this would be very helpful.  I struggled a bit to get Windows build working, for example, because I didn't know the exact pattern to put in ldc2.conf at first. I tried various combinations that didn't work until I accidentally landed upon "x86_64-.*-windows.msvc" (the Wiki page was confusing; it's either outdated or incomplete, as I was trying "i686-.*-windows.*" to no avail).

Having this automated would be Very Nice indeed.


> Step 3 includes selecting a C cross-linker for most targets and could be simplified to just specifying the NDK path for Android targets.
> 
> Usage would be something like:
> 
> $ ldc-add-target android-aarch64
> Enter path to Android NDK: /path/to/android-ndk-r20b
> $ ldc2 -mtriple=aarch64-linux-android ...
> ...
> $ ldc-add-target windows-x64
> $ dub --arch=x86_64-windows-msvc ...
[...]

This is awesome stuff.  My current Android still uses Joakim's old guide that involves manually specifying a lot of stuff like explicit linker options, library and SDK paths, etc., on the command line. True, I only had to do it once and thereafter just put it in the build script, but having a standard automated scheme to abstract away such details would make it a lot more pleasant to use.

LDC is quickly becoming my go-to D compiler esp. because of this ease of targeting other platforms. With superior codegen and ability to cross-compile to Windows, Android, etc., without needing VMs, dual-boot, separate cross-compiler installation, or any of that hassle, I'm quickly running out of reasons to use dmd anymore.  LDC is awesome (and so is the LDC team).


T

-- 
Two wrongs don't make a right; but three rights do make a left...