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).

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?

--
Paulo

On Thursday, 21 November 2013 at 22:02:14 UTC, 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?
>
> --
> Paulo

Everything accessible from Java is also accessible from NDK (by using reflection or by calling Java code from C++), so saying "NDK only covers game related APIs" is somewhat wrong.

I can only tell about our application, but it has a lot of JNI code. It is mostly used as a message passing mechanism between  Java and C++ (which live in separate threads so that Java GC doesn't stop native code execution).

It's still experimental, but offloading some of the Java logic to C++ gave as a significant performance boost, especially noticeable on low-end devices.

A good example of the Java/C++ mix is a Chrome browser in Android. I'd say it's 50% Java/50% C++ (not counting the WebKit part).

Am 21.11.2013 23:33, schrieb inout:
> On Thursday, 21 November 2013 at 22:02:14 UTC, 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?
>>
>> --
>> Paulo
>
> Everything accessible from Java is also accessible from NDK (by using
> reflection or by calling Java code from C++), so saying "NDK only covers
> game related APIs" is somewhat wrong.

I know, but I was addressing it from the pure point of view. Specially when you compare C++ programming with NDK and what iOS/WP 8 SDKs offer to C++ developers.


>
> I can only tell about our application, but it has a lot of JNI code. It
> is mostly used as a message passing mechanism between Java and C++
> (which live in separate threads so that Java GC doesn't stop native code
> execution).
>
> It's still experimental, but offloading some of the Java logic to C++
> gave as a significant performance boost, especially noticeable on
> low-end devices.
>
> A good example of the Java/C++ mix is a Chrome browser in Android. I'd
> say it's 50% Java/50% C++ (not counting the WebKit part).

That was what I was expecting.

Currently I am using C++ for a small graphics demo that should be multiplatform across OS handsets.

Thanks for the feedback.


--
Paulo

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

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

On Friday, 22 November 2013 at 05:30:00 UTC, Paulo Pinto wrote:
> 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

> 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.

almost:

http://developer.android.com/reference/android/app/NativeActivity.html

On Friday, 22 November 2013 at 07:48:34 UTC, eles wrote:
> On Friday, 22 November 2013 at 05:30:00 UTC, Paulo Pinto wrote:
>> 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
>
>> 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.
>
> almost:
>
> http://developer.android.com/reference/android/app/NativeActivity.html

That is a Java class full of native methods for calling into native code from Dalvik.

Now lets say you are doing a game, so NDK already provides the necessary C, C++, OpenGL libraries.

Do you want to use Renderscript for GPGPU code? Well if targeting Android versions lower than 4.4, you need to write the JNI bindings yourself.

Do you want to allow the players to share their games achievements via Google Play Game Services?

Then you need to write the JNI bindings yourself. But fear not, Google has made a video about it, http://www.youtube.com/watch?v=dxI5bReatJw. Lets see if part 2 ever comes up.

If you need more than graphics, sound or sensors manipulation, then you need JNI.



--
Paulo

On 2013-11-22 06:30, Paulo Pinto wrote:
 that Google leaves to the developers the effort of
> creating the JNI wrappers themselves, instead of providing a nice C++
> API for them.

I guess they want their developers to use Java. Otherwise they would have made C++ a first class citizens and not force C++ to go through Java.

-- 
/Jacob Carlborg

On Friday, 22 November 2013 at 12:45:19 UTC, Jacob Carlborg wrote:
> On 2013-11-22 06:30, Paulo Pinto wrote:
>  that Google leaves to the developers the effort of
>> creating the JNI wrappers themselves, instead of providing a nice C++
>> API for them.
>
> I guess they want their developers to use Java. Otherwise they would have made C++ a first class citizens and not force C++ to go through Java.

Certainly, that is also one of the reasons why they have come up with Renderscript and are now moving to native compiled Java post KitKat.

I don't have any issue with Java and do like the language, but it has lost its place if you care about portable code across mobile platforms.

Hence why I am using C++, as it is the only common language across all SDKs thus requiring minimal setup to get going.


--
Paulo