Running D in the Java VM

[Paulo Pinto]

Am 22.11.2013 00:52, schrieb John J:
> On 11/21/2013 05:02 PM, Paulo Pinto wrote:
>> Am 21.11.2013 21:25, schrieb inout:
>>> On Thursday, 21 November 2013 at 07:35:01 UTC, Volcz wrote:
>>>> On Sunday, 17 November 2013 at 05:49:43 UTC, John J wrote:
>>>>> On 11/15/2013 02:13 AM, Jeremy DeHaan wrote:
>>>>> If it should survive as an alternative, Jave should have some more
>>>>> advantages over D, even after the D compiles to ARM.
>>>>
>>>> The Android NDK is only a second class citizen compared to the Java
>>>> SDK. The only use case I have heard of for the NDK is when companies
>>>> have a small C library with common functionality to make porting the
>>>> products to other platforms easier.
>>>
>>> That's not true. Most games are written entirely with NDK. Many
>>> applications, too (the app my team shipped recently contains a fair
>>> amount of C++ code in it, and it only grows).
>>
>> NDK only covers game related APIs, mostly.
>>
>> How much JNI calls do you make in standard applications?
>>
>
> Another language, Delphi also uses the NDK for full Android applications.
> It creates a .so lib file for each application along with a minimal Java
> class that loads the native code.
>
> http://blog.marcocantu.com/blog/compiling_android_apps_delphi.html
>

There are lots of them, that is not the point.

The problem is that Android's API is mainly Java, which forces JNI 
marshalling and control switch between Dalvik and native code.

So if you care about performance in native code, you need to take care 
how Android APIs are being called.

Otherwise the performance benefits of native code vs Dalvik are throw 
out of the window.

Not to mention that Google leaves to the developers the effort of 
creating the JNI wrappers themselves, instead of providing a nice C++ 
API for them.

--
Paulo