Discussion :

[Traroth2]

Le Java est un langage semi interpreter donc si ca a son importance ...
Et peu importe la machine virtuelle ... Java restera moins performant qu'un langage natif.

Et ne me faites pas dire ce que je n'ai pas dis ...
Y'a des jeux biens fouttus en Java ... mais il y a moins de possibilitee du a l'overhead apporter par la VM par rapport a un langage natif.

De plus je n'ai aucunement parler de puissance de langage ...
On peut tout pratiquement tout faire en Java (j'ai pas vu de drivers en Java ) ... mais on revient toujours a la meme limitation par rapport au langage natif : la gourmandise de la VM.

Une des solutions autres que l'utilisation des langages natifs: l'embarquement d'un processeur Java (oui ca existe) ... apres faut voir niveau autonomie ...

Et oui les jeux videos ont leur places maintenant sur telephone mobile.
Perso entre me trimballer entre 1 console portable + 1 telephone + 1 lecteur mp3 + 1 appareil photo d'appoint et un telephone qui integre tout cela ...
On assiste a ce qu'on appel la convergence numerique et c'est pas plus mal ... ca va nous permettre d'alleger nos poches .

L'un des autres gros problemes dans l'histoire c'est pour les editeurs faisant souvent des applis natives et voulant passer sur Android .... bim faut re-ecrire tout le code natif en Java = cout supplementaires.
Apres ca peut etre compenser par le fait que ce code sera re-utilisable sur tous les phones Android et n'est pas specifique a un telephone.

Android supporte OpenGL ES (comme l'iPhone), et les appels sont simplement wrappés dans l'API. Donc tu développes en Java, mais derrière, Dalvik appelle simplement OpenGL ES. C'est pareil pour les appels à SQLite. Donc non, ça n'a strictement aucune importance.
De plus, beaucoup de technologies executent les applications dans un environnement managé qui s'apparente beaucoup à la JVM ou à Dalvik. C'est le cas de .Net sous Windows et Windows Mobile, par exemple. Pour l'iPhone, je ne connais pas, mais je serais surpris que ça ne soit pas le cas.

[FloMo]

Android supporte OpenGL ES (comme l'iPhone), et les appels sont simplement wrappés dans l'API. Donc tu développes en Java, mais derrière, Dalvik appelle simplement OpenGL ES. C'est pareil pour les appels à SQLite. Donc non, ça n'a strictement aucune importance.

OpenGL ES ne gère que la partie graphique. Tous les événements sont gérés en Java sinon.

De plus, beaucoup de technologies executent les applications dans un environnement managé qui s'apparente beaucoup à la JVM ou à Dalvik. C'est le cas de .Net sous Windows et Windows Mobile, par exemple. Pour l'iPhone, je ne connais pas, mais je serais surpris que ça ne soit pas le cas.

Sous Windows Mobile, c'est .Net Mobile et C / C++. Pour la partie OpenGL ES, ce sera C / C++, qui est le langage utilisé nativement par le système.

Pour L'iPhone, on utilise Objective-C et C. Objective-C est une surcouche au C, à l'instar du C++ mais plus orienté événementiel et d'une syntaxe bien différente.

Pour Symbian, c'est aussi du C et du C++.

En gros, sur Symbian, iPhone et Windows Mobile, tu reprends ton code C / OpenGL ES et tu modifies les quelques parties vraiment propres à la plateforme.

Sur Android, tu recodes la majeure partie en Java et tu apportes en plus les optimisations spécifiques à la plateformes.

C'est pourquoi si Android avait un SDK autre que Java ce serait plus accessible aux développeurs de jeux vidéos.

Enfin, je me trompe peut-être sur certaines parties n'étant pas spécialiste du jeu vidéo. Par contre, c'est sûr que l'OpenGL ES ne fait que simplifier la portabilité de l'accélération matérielle et non pas l'intégralité de l'application.

[MrDuChnok]

http://developer.android.com/sdk/ndk/1.6_r1/index.html
Il y a également un NDK pour développer en code natif (c++)

[deadalnix]

Il y a une bonne discution la dessus dans al partie JV.

Ce qu'on peut en conclure, c'est que java, c'est tout à fait adapté au JV pour peu que les parties demandant beaucoup de sauce soient gérées en natif . . . comme avec opengl es par exemple.

Pour le reste, on a de tout façon pas la puissance dans un smartphone pour faire de la physique 3D temps réel ou de l'IA très poussée. Pour ce qui n'est pas en temps réel, ça importe peu.

Donc non, ça ne me semble pas être un soucis majeur.

Le soucis majeur de java, c'est pas tant le langage et la JVM, mais plutôt la piètre qualité du code java en général.

Et le gros point fort d'androide sur les iphone like, c'est d'être ouvert.

Pour ce qui est du multi tache, androide laisse la main à l'utilisateur plutôt que de lui imposer des choix. Alors que sur iPhone apple fait les choix a ta place (multitache, softs dont tu as besoin, tout doit passer par apple).

Si le marché du smartphone se développe autant qu'on nous le promet, ça devrait faire la différence.

[Uther]

La GROSSE faiblesse d'Android est l'utilisation du langage Java pour l'élaboration des softs, à moins que je ne me trompe mais ce langage n'est pas asser performant pour faire des jeux aussis bien fouttus que sur iPhone ...
Le nerf de la guerre ce n'est pas seulement les aplications qu'on peut avoir sur tel ou tel téléphone .... mais surtout le multimédia et les JEUX!
Pour ma part, tant qu'Android ne proposera pas des jeux aussi poussés que sur iPhone ... Android gardera sa place de bon second.

Autant c'est vrai que les jeux ont pu être un vrai moteur pour l'évolution des technologie a une époque, je ne crois pas que ce soit le cas aujourd'hui. Ce qui est le moteur des smarthphone c'est avant tout les capacités de communication : l'internet, les réseaux sociaux, ...
Quand on joue sur portable, on ne s'attache pas tant que ça a la qualité des graphismes, d'autant plus que le public des smartphone est beaucoup moins geek que les PC a l'époque.

On me dira qu'on peut développer en natif' sous Android en bidouillant son image Android et avec un cross compiler ou bien avec le NDK .... mais j'aimerais surtout voir quelque chose de plus officiel et plus complet que le NDK ou les bidouilles ...

Le NDK est officiel et il permet maintenant d'accéder a l'API openGL, ce qui devrait permettre de l'utiliser efficacement pour faire des jeux.

Et là on arrive à la seconde faiblesse d'Android : pas de standardisation de la plateforme hardware ...
Effectivement, qui dit processeur d'architecture différente ... dit difficultées d'avoir un code tournant natif' tout en ayant une bonne compatibilitée ...

En effet l'iPhone est plutôt dans la situation des consoles de jeu : un seul modèle connu avec peu de variantes sur lequel on doit faire du développement plutôt spécifique et ou le constructeur doit approuver la diffusion des application en prenant sa part.
Au contraire Androïd ressemble plus au fonctionnement d'un PC: un matériel hétérogène qui permet d'installer librement ce que l'on souhaite.

Donc en effet si on vois son smarthphone comme une console de jeu, le faible nombre d'iPhone différents est un avantage.
Par contre si on voit son smartphone comme un PC, sur lequel on peut faire ce que l'on souhaite et avoir quelque chose d'adapté a ces besoin, android est plus intéresssant.

[kurapix]

Les capacités de communication tous les bons smartphones l'ont de base ... ce n'est pas ce qui va aider à différencier un smartphone d'un autre.
On est d'accord pour dire que les smartphones ne sont pas des consoles de jeux.
Mais un smartphones digne de ce nom est capable de faire tourner un jeu 3D ... on peut pas comparer ça à un PC mais c'est quand même sympa d'avoir de bons jeux sur smartphones ...

De plus ça me fait penser à un sujet que j'avais vu sur l'iPhone : le piratage des applications. Sous Android, dû à Java .... il est presque impossible de protéger efficacement ses applications ... (notament dû aux techniques de décompilation poussée et précise qui existent pour le Java et autres langages semi-interprétés/semi-compilés).
Ensuite ça c'est un autre sujet ...

Pour l'instant j'attend de voir mais Android est une plateforme intéressante au vu de son ouverture. Et ça démocratisera au moins les smartphones sous Linux .

kurapix

[Uther]

De plus ça me fait penser à un sujet que j'avais vu sur l'iPhone : le piratage des applications. Sous Android, dû à Java .... il est presque impossible de protéger efficacement ses applications ... (notament dû aux techniques de décompilation poussée et précise qui existent pour le Java et autres langages semi-interprétés/semi-compilés).
Ensuite ça c'est un autre sujet ...

C'est bien connu que les applications iPhones ne sont pas piratées,...

Il est presque impossible de protéger efficacement ces applications qu'elles soient compilées en language machine ou non.
Un code java compilé sans infos de débugge et passé dans les mains de progruard n'est pas vraiment plus lisible qu'un code machine.

Au final la seule différence est que le langage d'assemblage utilisé a une syntaxe différente. D'ailleurs on peut tout a fait exécuter un code machine dans une VM, c'est le principe d'un émulateur.

[spidermario]

Le Java est un langage semi interpreter donc si ca a son importance ...
Et peu importe la machine virtuelle ... Java restera moins performant qu'un langage natif..

Encore une fois, c'est l'implémentation principale qui consiste en une semi-compilation.
GCJ, par exemple, compile le code Java en exécutable natif.

[robert_trudel]

La GROSSE faiblesse d'Android est l'utilisation du langage Java pour l'élaboration des softs, à moins que je ne me trompe mais ce langage n'est pas asser performant pour faire des jeux aussis bien fouttus que sur iPhone ...
Le nerf de la guerre ce n'est pas seulement les aplications qu'on peut avoir sur tel ou tel téléphone .... mais surtout le multimédia et les JEUX!
Pour ma part, tant qu'Android ne proposera pas des jeux aussi poussés que sur iPhone ... Android gardera sa place de bon second.

hum une bonne partie des softs disponible sur mobile sont des soft java
même quake 2 avait été porté en java...

tu peux très bien bien ne pas utiliser une jvm pour faire rouler une application java, il existe quelques possiblité pour faire ça, par contre rien ne garantie que les performances seront meilleurs

comme tu dis pour ta part.... la vie ce n'est pas juste soi-même

Et là on arrive à la seconde faiblesse d'Android : pas de standardisation de la plateforme hardware ...
Effectivement, qui dit processeur d'architecture différente ... dit difficultées d'avoir un code tournant natif' tout en ayant une bonne compatibilitée ....

kurapix

androit supporte différents processeur, ce qui lui permet d'être installé sur un plus grand nombre de machine, du cadre photo, au ebook en passant par le netbook et le mobile...

il fonctionne déjà sur x86, arm, ppc, mips, or pour ce qui est du téléphone mobile arm détient le marché donc si quelqu'un veut réelement faire du natif pour le téléphone mobile, il va ciblé la plateform arm...


pour les connaisseurs, certain cpu arm utilise une technique pour améliorer les performances de java, je me demande si c'est applicable pour la vm de google?

[robert_trudel]

Le Java est un langage semi interpreter donc si ca a son importance ...
Et peu importe la machine virtuelle ... Java restera moins performant qu'un langage natif.


Et ne me faites pas dire ce que je n'ai pas dis ...
Y'a des jeux biens fouttus en Java ... mais il y a moins de possibilitee du a l'overhead apporter par la VM par rapport a un langage natif.

rien n'emêche de compiler du java avec gcj ou bien d'utiliser Excelsior JET
tout dépend des opérations, une multitude de test démontre que java peut être plus rapide que le c, c++ sur certaine opération et l'inverse sur d'autre

De plus je n'ai aucunement parler de puissance de langage ...
On peut tout pratiquement tout faire en Java (j'ai pas vu de drivers en Java ) ... mais on revient toujours a la meme limitation par rapport au langage natif : la gourmandise de la VM.

la vm de google a été optimisé justement pour les machines ayant peu de mémoire, il n'y a pas de JIT

L'un des autres gros problemes dans l'histoire c'est pour les editeurs faisant souvent des applis natives et voulant passer sur Android .... bim faut re-ecrire tout le code natif en Java = cout supplementaires.
Apres ca peut etre compenser par le fait que ce code sera re-utilisable sur tous les phones Android et n'est pas specifique a un telephone.

ça c'est la réalité de toute les jours... si tu prends une applications du genre document to go... qui a démarré sous palm.. tu crois vraiment que ça fonctionné comme par magie sur blackberry os, windows mobile, iphone?

[robert_trudel]

Les capacités de communication tous les bons smartphones l'ont de base ... ce n'est pas ce qui va aider à différencier un smartphone d'un autre.
On est d'accord pour dire que les smartphones ne sont pas des consoles de jeux.
Mais un smartphones digne de ce nom est capable de faire tourner un jeu 3D ... on peut pas comparer ça à un PC mais c'est quand même sympa d'avoir de bons jeux sur smartphones ...

De plus ça me fait penser à un sujet que j'avais vu sur l'iPhone : le piratage des applications. Sous Android, dû à Java .... il est presque impossible de protéger efficacement ses applications ... (notament dû aux techniques de décompilation poussée et précise qui existent pour le Java et autres langages semi-interprétés/semi-compilés).
Ensuite ça c'est un autre sujet ...

Pour l'instant j'attend de voir mais Android est une plateforme intéressante au vu de son ouverture. Et ça démocratisera au moins les smartphones sous Linux .

kurapix

tu as absolument aucune garantie de sécurité avec une application compilé, bien avant que java existe, tu avais accès à des keys générateur pour toutes les grosses applications du marché...

comment tu penses que ses keys générateurs sont fait?

en prenant l'exécutable du programme, en le décompilant, tu te retrouves alors avec du code assembleur... et tu navigues dans le code pour trouvé ou les opérations de validation/vérifications sont faites....

ce problème existe pour n'importe quel langage... avec un peu de patience et les capacités techniques toute protection se casse

fait à noté, il y a une news justement sur clubic à propos du piratage sur iphones... http://www.clubic.com/actualite-3078...ux-iphone.html

[robert_trudel]

Le soucis majeur de java, c'est pas tant le langage et la JVM, mais plutôt la piètre qualité du code java en général.

est-ce que tu as des statistiques sur le sujet?

à moins que je me trompes mais la majorités des logiciels du commerce était codé en C++ jusqu'à tout récemment, j'ai pas encore vu d'application sans bug... ce qui fait que le code C++ en général est de mauvaise qualité?

[deadalnix]

Non, mis par contre, je suis sur que tu as vu tout plein d'application java ayant la même énergie qu'un viel ane mort.

A tel point que plein de gens pensent que java c'est forcement lourd, lent, et tout ce qui s'en suis.

Alors que dans les faits, un programme java bien foutu, ça tourne bien, et même très rapidement.

Ceci dit, le problèmes n'est pas limité à java : la qualité du code globalement est en baisse. Et il n'y a pas de secrets : il y a besoin de plus en plus de code, donc on est de moins en moins regardant sur les codeurs.

Des langages tels que java ont ceci de magique qu'on peut faire pratiquement n'importe quoi et que ça marche quand même. C'est une aubaine.

Je ta garantis un truc : fait n'importe quel salon de l'emploie avec Java J2EE sur ton CV, et tu repars avec pratiquement autant d'entretiens d'embauche que de stand si tu le souhaites.

J'en connais qui aujourd'hui font du java qui n'ont jamais réussit à utiliser correctement un pointeur.

J'ai rien contre java en particulier. Ce n'est parce que tu es un pro de l'orientation que tu ne dois pas utiliser un GPS. Mais ce n'est pas non plus parce que tu sais retrouver ton chemin avec un GPS que cela fait de toi un pro de l'orientation.

La baisse de qualité est la aussi en C++. Sauf qu'en C++, si ça baisse trop, au bout d'un moment ça ne marche plus du tout.

[kurapix]

tu as absolument aucune garantie de sécurité avec une application compilé, bien avant que java existe, tu avais accès à des keys générateur pour toutes les grosses applications du marché...

comment tu penses que ses keys générateurs sont fait?

en prenant l'exécutable du programme, en le décompilant, tu te retrouves alors avec du code assembleur... et tu navigues dans le code pour trouvé ou les opérations de validation/vérifications sont faites....

ce problème existe pour n'importe quel langage... avec un peu de patience et les capacités techniques toute protection se casse

fait à noté, il y a une news justement sur clubic à propos du piratage sur iphones... http://www.clubic.com/actualite-3078...ux-iphone.html

Je sais de quoi je parle un minimum bien que je ne sois pas un expert ...
Un code natif c'est beaucoup plus difficile a decompiler ...
Et t'as plus de possibilitees d'obfuscation ...
Et on ne peut parler de garantie de securite nul part ... car le risque zero n'existe pas mais on essaie d'y tendre.

Les langages semi-interpretes/semi-compiles auront toujours ce(tte) benediction/probleme ... celui de pouvoir se faire mieux decompiler que les langages natifs ...

Je peux en tout cas t'assurer que c'est bien plus facile d'analyser un bytecode Java qu'un binaire x86 ...

kurapix

[deadalnix]

C'est sur, mais une fois passé à l'obfuscation, ça change finalement plus grand chose. Un acharné y arrivera dans les deux cas.

Pour ce qui est de la sécurité, le code managé ne fait pas de buffer overflow . . .

[bizzard4]

Bonjour !

En lisant ce thread je suis tombé par hasard sur un site qui fait des benchmark Java / C sur Android.

http://code.google.com/p/android-benchmarks/

D'un coup d'œil nous pouvons rapidement voir que les applications en C sont + si ce n'est pas +++ rapide que les applications en Java.

Malheureusement pour les pro Java, Java est réputé pour être lent et avec raison. La plupart des applications développées en Java on une interface lente, mais je n'ai pas les qualification et l'expérience pour donner un verdict personnel sur le core par contre.

Voici une petite liste d'applications connus à interface lente en Java que j'ai eu à utiliser (spéculation sur l'interface en Java, mais certain trais du Java sont immanquables)
- Visual Paradigm http://www.visual-paradigm.com/
- Rational Rose de IBM http://www-01.ibm.com/software/awdtools/developer/rose/
- AutoCAD Electrical http://usa.autodesk.com/adsk/servlet...&siteID=123112
(Il est à noter que pour le dernier, Electrical n'est pas "trop" utilisé et que dès que nous allons vers un logiciel de Autodesk populaire, comme 3D studio max, il est en C++ avec interface comprise et c'est très performant)

De plus, aillant une expérience professionnel dans le développement de jeuxvideo, je dois avoué que aucun langage se rapproche à la rapidité d'exécution du C++ Natif.

Et franchement, à ceux qui crois qu'il peu y avoir des jeux performants sur Android... donnez des exemples. J'ai un Android, avec des jeux, qui lag tous... sans exception. C'est dommage j'ai vraiment cru que Google serait un vrai compétiteur à Apple.

Sur ce, bon débat

[robert_trudel]

Je sais de quoi je parle un minimum bien que je ne sois pas un expert ...
Un code natif c'est beaucoup plus difficile a decompiler ...
Et t'as plus de possibilitees d'obfuscation ...
Et on ne peut parler de garantie de securite nul part ... car le risque zero n'existe pas mais on essaie d'y tendre.

Les langages semi-interpretes/semi-compiles auront toujours ce(tte) benediction/probleme ... celui de pouvoir se faire mieux decompiler que les langages natifs ...

Je peux en tout cas t'assurer que c'est bien plus facile d'analyser un bytecode Java qu'un binaire x86 ...

kurapix

tu peux utiliser des logiciels pour obfusquer le code... il reste que tu as keygenerator pour tous les gros programmes du marché... aucun avantage

[Rapha222]

Bonjour !

En lisant ce thread je suis tombé par hasard sur un site qui fait des benchmark Java / C sur Android.

http://code.google.com/p/android-benchmarks/

D'un coup d'œil nous pouvons rapidement voir que les applications en C sont + si ce n'est pas +++ rapide que les applications en Java.

En effet, on dirait que c'est bien une machine virtuelle (comme les veilles versions de Java) et non une JIT, dommage. Mais c'est logique aussi (Android ne se limite pas à une architecture).

Malheureusement pour les pro Java, Java est réputé pour être lent et avec raison. La plupart des applications développées en Java on une interface lente, mais je n'ai pas les qualification et l'expérience pour donner un verdict personnel sur le core par contre.

C'est l'interface justement (swing et compagnies) qui donnent cette impression de lenteur et de manque de réactivité. Les applis .NET qui utilisent la même architectures sont aussi réactives que les natives (ou a peu de choses près), que ce soit sur Windows avec les Winforms/WPF (Paint.NET) ou sur Linux avec GTK (Banshee) ou QT puisque ça se passe avec des appels natifs et non pas une GUI écrite 100% en Java.

De plus, aillant une expérience professionnel dans le développement de jeuxvideo, je dois avoué que aucun langage se rapproche à la rapidité d'exécution du C++ Natif.

Et franchement, à ceux qui crois qu'il peu y avoir des jeux performants sur Android... donnez des exemples. J'ai un Android, avec des jeux, qui lag tous... sans exception. C'est dommage j'ai vraiment cru que Google serait un vrai compétiteur à Apple.

Sur ce, bon débat

Je me demande jusqu'à quel niveau il est possible d'utiliser le SDK natif sur Android. Est-ce que des jeux pourraient êtres codés 100% en natif ?

[robert_trudel]

En effet, on dirait que c'est bien une machine virtuelle (comme les veilles versions de Java) et non une JIT, dommage. Mais c'est logique aussi (Android ne se limite pas à une architecture).

effectivement pas de JIT pour android

2 tests c'est vraiment trop peu juger des performances d'android en plus avec un test sur un algo récursif

C'est l'interface justement (swing et compagnies) qui donnent cette impression de lenteur et de manque de réactivité. Les applis .NET qui utilisent la même architectures sont aussi réactives que les natives (ou a peu de choses près), que ce soit sur Windows avec les Winforms/WPF (Paint.NET) ou sur Linux avec GTK (Banshee) ou QT puisque ça se passe avec des appels natifs et non pas une GUI écrite 100% en Java.

c'est plutôt le programmeur qui sait pas utiliser swing qui fait en sorte que l'interface soit si lente

à moins d'être vraiment aveugle, on voit aisément que l'application utilise .net

si tu veux des appels natif, faut utiliser swt avec tous les problèmes que ça emmène

tu as toujours la possibilité d'utiliser java 2d... afin que les opérations passe par l'accélération matériel

la vm d'android est encore jeune, il y a encore de la marge avant qu'elle atteigne le niveau de celle de sun, ce qui est intéressant, c'est qu'elle progresse très rapidement

[Gordon Fowler]

Android 2.1 a été repéré sur le Net