JTransc + Android/iOS status support

[Joakim via Digitalmars-d]

On Tuesday, 29 November 2016 at 01:09:19 UTC, soywiz wrote:
> On Monday, 28 November 2016 at 17:53:30 UTC, Joakim wrote:
>> On Monday, 28 November 2016 at 14:28:54 UTC, soywiz wrote:
>>> I am working on a software that allows to transform JVM 
>>> bytecode into something else. In last version I have done a D 
>>> target: https://github.com/jtransc/jtransc
>>> D target already passes my test suite and works just fine 
>>> (next version will come with some optimizations regarding to 
>>> code generation that will improve generation).
>>> At this point I'm successfully generating windows/linux and 
>>> mac native executables from Java/Kotlin code.
>>
>> Interesting, might provide a better bridge for Java 
>> compatibility on Android.
>>
>>> It would be awesome to be able to support Android and iOS. I 
>>> have seen that there was Android/iOS alpha support in the 
>>> past. What is the current status of this?
>>
>> Android support is in beta, latest cross-compiler and native 
>> builds here:
>>
>> https://github.com/joakim-noah/android/releases
>>
>> I've been seeing random crashes for apk builds recently, 
>> trying to track down why.  I've ported the Teapot OpenGL ES 
>> 2.0/C++ sample app from the NDK, but it's got some bugs, 
>> debugging that next.  Once both issues are fixed, I'll 
>> announce the beta in a new thread.
>>
>> As for iOS, Dan has been busy with other stuff, may get back 
>> to it sometime this winter.  All mobile builds are linked from 
>> the main download page, under ldc:
>>
>> http://dlang.org/download
>
> Thanks you both for the info!
>
> I have seen those links already. I was a bit concerned about 
> the support, since it is outside the main development. It is 
> planned to be merged in the main projects? Or those were just 
> experiments? It would be great to have full support from the 
> community that seems to be pretty active lately at github so it 
> doesn't end being outdated.

Dan, who is behind the iOS/watchOS/tvOS port, and I, Android 
port, are both committers to the ldc project, which has an ARM 
backend unlike dmd, and most of our mobile ports have been merged 
upstream:

https://github.com/ldc-developers/ldc/commits?author=smolt
https://github.com/ldc-developers/ldc/commits?author=joakim-noah

There are a few remaining issues that need to be polished up 
before the ports are fully merged, but the goal is for all mobile 
development to be in the main ldc repo, with official ldc builds 
for mobile released eventually.

Of course, how fast that happens also depend on how many users 
and other ldc developers get involved in the mobile effort, 
something we cannot control.

> When considering a new target for jtransc i was searching for a 
> language like c++ that allowed to generate native executables, 
> with gc already included, with safety in mind, and full oop 
> included while allowing to go low level when required. And that 
> was exactly D. So I can mix both of the two worlds and mix code 
> as required (performant parts in D, and higher 
> level/productivity in kotlin).
>
> In the case D targets every major popular platforms (including 
> mobile) it would be great, since i can generate javascript for 
> the web already and d for desktop+mobile covering all my 
> current needs. Instead of having to implement a gc for c++. 
> Also D has faster compilation times than it which is great.

You're in the right place. :)

> I will try both projects asap. If it works I will try to port 
> libgdx to jtransc+d+android/ios.

Let me know if you have any problems.  I think the random apk 
issues I'm seeing could be a regression or new incompatibility in 
the ld.bfd linker, but I need to track it down.

> Even when in Android I can run Java directly. I think there is 
> still a point for it. Android doesn't support java8 directly 
> and it can be running either dalvik or art. Also it is easily 
> decompilable. So a native with unknown optimizations depending 
> on the versio  AOT could make performance much more predictable 
> among versions, obfuscate it, allow to use stuff like simd, or 
> support higher java versions.

Yes, ART is AoT-compiled also, so Android has also moved there 
since 5.0.