Discussion :

[Idelways]

Développer pour Android sans Java bientôt possible
En C++ grâce à la 5ème révision du Native Development Kit



Développer des applications pour Android 3 (ou ultérieur), entièrement en C++, sans la moindre ligne de Java sera bientôt possible d'après un billet publié sur le blog officiel des développeurs Android par Chris Pruett.

Une nouvelle qui devrait surtout intéresser les développeurs de jeux vidéo 3D, un domaine où les applications Java affichent parfois des limites en terme de performances.

Cette nouvelle devrait aussi ravir les développeurs C/C++ et ceux qui ne s'inquiète de l'avenir de Java suite à son passage sous l'égide d'Oracle, à l'origine d'une action en justice toujours en cours, contestant l'utilisation de Java sur Android.

Utiliser des librairies natives en C/C++ à partir d'applications écrites en Java pour Android était déjà possible grâce au Native Development Kit (NDK) disponible dans sa première version depuis juillet 2009.

Depuis cette version, l'équipe du projet a intégré dans plusieurs révisions des fonctionnalités clés à son Kit de développement : le support de OpenGL ES, le débogage, le support de multiples ABI (interface binaire-programme) et l'accès aux bitmaps à partir du code natif.

Dans la cinquième et prochaine révision (NDK r5), Google introduira des APIs qui permettront aux développeurs de s'affranchir entièrement de l'utilisation de Java : "Avec ces outils, les applications visant Android Gingerbread ou ultérieure pourront être implémentées entièrement en C++" déclare Chris Pruett.

"Vous pouvez maintenant écrire des applications pour Android sans avoir à écrire la moindre ligne de Java" insiste Pruett.

Cependant, les applications développées de la sorte dépendront toujours de Dalvik (la machine virtuelle Java de Google) notamment pour les appels à l'API d'Android.


Source : le blog de Android Developer

Et vous ?

Que pensez-vous de cette nouvelle ? S'agit-il d'un début de réponse à Oracle ?
Allez-vous développer en C++ pour Android ?

[air-dex]

Que pensez-vous de cette nouvelle ?

Bonne nouvelle. Se passer de Dalvik (à terme) ne peut être que bénéfique pour Android dont on pourrait tirer plus de puissance.

[Neko]

Je comprends pas bien pourquoi les appels aux API dépendent toujours de Dalvik

[gros_rougeot]

On va enfin pouvoir coder sérieusement sur android sans avoir besoin d'écrire 5 lignes, ni utiliser 10 classes pour faire un truc simple.

Beaucoup sautent sur leur chaise comme des cabris en disant "java", "java", "java" ! mais qu'est cela (java) est lourd et au bout du compte pas des plus efficace.

[Priato]

On va enfin pouvoir coder sérieusement sur android sans avoir besoin d'écrire 5 lignes, ni utiliser 10 classes pour faire un truc simple.

Beaucoup sautent sur leur chaise comme des cabris en disant "java", "java", "java" ! mais qu'est cela (java) est lourd et au bout du compte pas des plus efficace.

Pour moi, le problème avec Java c'est plutôt sa machine virtuelle(ici Dalvik) qu'il faut qu'il y ait derrière. Je code bien plus vite en Java qu'en C++, par contre niveau performance dans l'exécution, c'est pas trop comparable(avec OpenGL par exemple).
Le fait de passer par Dalvik, supprime, selon moi tous les avantages de passer en C++.
Je pense donc continuer à développer en Java sur cette plateforme...
Si par contre à terme, Dalvik venait à être supprimé (pour l'exécution de code C++), et que j'ai des applications lourdes à développer, je reviendrai à mon bon vieux C++.

@gros_rougeot: Tu trouves qu'il faut plus de lignes de code en Java pour faire la même chose qu'en C++? C'est pas plutôt l'inverse? (sans parler d'héritage multiple bien sur...)

[Guildem]

Te plain pas gros_rougeot, ils auraient pu faire leurs api en flash et intégrer la vm d'adobe

Très bonne chose de pouvoir bientôt développer en c++ directement, toute la puissance d'Android et surtout des smartphones/tablettes enfin disponible en totalité !

[ratomms]

Développer en C++ pourrait améliorer la performance des applications qui tournent sous Android. Mais du point de vue préférence,j'adore JAVA.

[Paul TOTH]

Ceci dit, on retombe sur les problèmes de compatibilité hardware, vu que tous les processeurs sous Android ne sont pas identiques

[abriotde]

Pour un compromis entre le C++ et le java, rapport performance, efficacité, simplicité de développement, personnellement je préfère le langage Go de Google. Compilé, mais avec un garbage collector... c'est fort.

[lequebecois79]

Pour un compromis entre le C++ et le java, rapport performance, efficacité, simplicité de développement, personnellement je préfère le langage Go de Google. Compilé, mais avec un garbage collector... c'est fort.

tu peux déjà avoir un GC avec le C++

ça va créer que plus de problème actuellement étant donné la variété de cpu qui font tourner android

Google n'a qu'à optimiser sa vm... voir droidbooster

[cedrix57]

Utiliser des librairies natives en C/C++

C'est quoi une librairie native ?
Qt est une librairie native ?

Merci d'avance

[renoo]

stlport + meme boost apparement

http://stackoverflow.com/questions/4...d-ndk-and-stlp

[ZeRevo]

On ne risque pas d'avoir de plus en plus d'appli planter ?

[jean-michel-78]

bonne nouvelle merci

[gorgonite]

Ceci dit, on retombe sur les problèmes de compatibilité hardware, vu que tous les processeurs sous Android ne sont pas identiques

pas forcement... il ne faut pas oublier qu'un code POSIX sera sûrement "portable source", et si google propose une belle chaîne de cross-compilation, il sera possible de compiler vers toutes les plateformes supportées

Pour un compromis entre le C++ et le java, rapport performance, efficacité, simplicité de développement, personnellement je préfère le langage Go de Google. Compilé, mais avec un garbage collector... c'est fort.

clairement avec C++ le niveau exigé pour concevoir et réaliser de "bonnes applis" pourrait augmenter...

il ne faut pas oublier le nombre de développeurs réussissant l'exploit d'avoir des codes plus lourds et plus lents en C++ qu'en Java...
et c'est sans parler de tous les plantages envisageables, comme signalé par ZeRevo

On ne risque pas d'avoir de plus en plus d'appli planter ?

après clairement, dans un monde idéal, les applis seront sûrement mieux optimisés, mais éventuellement avec un système de package plus complexe pour gérer à la fois les versions et les plate-formes supportées

[ymoreau]

C'est une sacré ouverture, le C++ reste quand même un langage très riche avec beaucoup de librairies. Cependant je pense aussi que plus y'a de libertés plus y'a de bugs.

[Nietsabe]

Le problème reste le même, certains "appels" dépendront toujours de la machine virtuel... En clair, on construit une autoroute C++ en parallèle à la nationale Java, mais la sortie d'autoroute débouche sur la nationale...

Bref, ça sera plus rapide pour certaines approches, mais ça ne sera jamais aussi rapide que de l'objective C sous iPhone... Dommage...

PS : je ne suis pas Pro-iPhone.

[Paul TOTH]

Le problème reste le même, certains "appels" dépendront toujours de la machine virtuel... En clair, on construit une autoroute C++ en parallèle à la nationale Java, mais la sortie d'autoroute débouche sur la nationale...

Bref, ça sera plus rapide pour certaines approches, mais ça ne sera jamais aussi rapide que de l'objective C sous iPhone... Dommage...

PS : je ne suis pas Pro-iPhone.

tout dépend de ce qui passera par Java...il n'y a pas si longtemps de cela pas mal d'applications étaient développées en Visual Basic pour construire l'interface graphique avec un coeur de métier en C++

si la partie C++ accède aux socket par exemple, il devient possible de faire du client/serveur en C++; qu'il faille passer par Java pour afficher deux ou trois infos à l'écran n'est pas très grave.

[Doksuri]

Je pense que ca permettra a Android de recuperer un paquet de developpeurs qui ne voulaient pas lacher leur C++ pour du JAVA...

Mais apres, j'espere qu'ils garderont la possibilite de continuer en JAVA pour ceux qui ne veulent pas le lacher pour le C++

plus il y a de developpeurs, moins y'a de riz...