Quelques explications sur le fonctionnement d’Android :
Si Google a choisi le Java, c’est pour que les applications puissent être exécutées indépendamment de la plateforme !
La réalité est un peu différente car en fait Google aurait pu choisir n’importe quel autre langage de programmation pour être indépendants de la plateforme (y compris le C) vu ce qu’Android fait du code Java … Ce qui permet à du code d’être exécuté de façon indépendante de la plateforme, c’est l’utilisation d’une machine virtuelle.
Justement, Java utilise une machine virtuelle, donc on peut bien dire que Google utilise le Java pour être indépendant de l’architecture machine, non ?
Non … Non car Google n’utilise pas la machine virtuelle Java … Google a créé pour Android sa propre machine virtuelle, la Dalvik Virtual Machine.
En temps normal, quand on code en Java, le code source est transformé en bytecode Java. Ce n’est pas ce qu’il se passe quand vous développez une application pour Android.
Oui votre code source est compilé en bytecode, mais pas en bytecode Java. Il s’agit d’un bytecode propre à Google. Ensuite, ce bytecode est exécuté par la Dalvik Virtual Machine, une machine virtuelle optimisée pour les plateformes avec une faible puissance. Un outil – dx – contenu dans le SDK d’Android transforme donc les classes java standard en classe spécial .dex.
Tout cela signifie que l’on aurait pu coder en C ou du .Net, par exemple, du moment que ce langage aurait été compilé sous la forme de bytecode.
Mais alors pourquoi utiliser du Java ?
Utiliser du Java pour le framework Android a un intérêt extrêmement important : celui d’attirer toute la communauté des développeurs d’applications pour téléphones mobiles, et surtout leur expérience en la matière. En effet, ces derniers travaillent déjà en Java, sont habitués à ce langage, à cette syntaxe, à ce mode de pensée (car le langage parlé ou codé influe sur votre façon de penser), etc. Autant ne pas les brusquer et s’attirer leur foudre, autant tout faire pour leur plaire.
Sur la licence enfin :
Bien que Java soit libre, le terme « java » reste soumis à de nombreuses conditions qu’impose le comité qui pilote son développement (respect du standard java principalement), de plus « java » est une Marque commerciale (Trademark). Google n’a donc pas intérêt à se répandre trop sur le terme. Nous détaillerons les choix de Google en termes de licence et ses rapports avec Sun dans un prochain article.
Envie de rejoindre une communauté de passionnés ? Notre Discord vous accueille, c’est un lieu d’entraide et de passion autour de la tech.
tg
Il me semblait que le java était juste bourré de faille et obsolète
[...] dans un premier lieu que RIM met à profit la licence d’Android, et en particulier celle de la Dalvik Virtual Machine, ou DVM, (ouh le vilain déterrage d’article), la solution technique qui exécute vos [...]
[...] un premier lieu que RIM met à profit la licence d’Android, et en particulier celle de la Dalvik Virtual Machine, ou DVM, (ouh le vilain déterrage d’article), la solution technique qui exécute vos [...]
[...] dans un premier lieu que RIM met à profit la licence d’Android, et en particulier celle de la Dalvik Virtual Machine, ou DVM, (ouh le vilain déterrage d’article), la solution technique qui exécute vos [...]
hey benh c'est pas récent toussa :)
[...] un premier lieu que RIM met à profit la licence d’Android, et en particulier celle de la Dalvik Virtual Machine, ou DVM, (ouh le vilain déterrage d’article), la solution technique qui exécute vos [...]
[...] pouvait le supposer, ou bien sinon le prévoir, au moins le prédire, Android va s’ouvrir à d’autres [...]
[...] effet, inutile de le rappeler Android, ce n’est pas du Java, mais ça se programme en [...]
Tu as tout à fait raison Alexis. Je n'ai poussé l'article jusque là car l'objet était avant tout de préciser que ce n'était pas commplètement vraiment du Java. Et je prenais le C en exemple par pur vulgarisation, mais effectivement cela n'aurait pas été adapté. Juste un petit bémol, Eclipse permet de faire tout (et n'importe quoi), y compris du C, du PHP, de la bureautique. Mais bien sûr, Eclipse sans plugins permet de faire du Java, et c'est pour cela que c'est utilisé principalement. En tout les cas merci de ton commentaire constructif et détaillé.
Pourquoi Java? Parce que c'est le langage qui se rapproche le plus de ce que Google souhaite, puisque 100% du langage Java 5 est aujourd'hui transposable vers le Runtime Davlik. Le C n'est pas un langage de développement Managé par un Runtime, il manipule directement la mémoire, c'est un langage non objet, il n'y a donc peu de choses qu'ils peuvent tirer du C. C# est déjà plus approprié, cependant, il permet lui aussi l'utilisation de pointeur, mais on peut imaginer se limiter à un subset du langage C# pour éviter l'accès à certaines fonctionnalités 'interdites' dans un environnement managé. De langages plus appropiés cependant pourraient très bien faire office: les langages de base ECMA, l'ActionScript, se prêtent parfaitement au jeu. En parallèle aux contraintes liées au langage, il y a l'outillage: Pourquoi Java? Parce que Eclipse fournit à l'heure actuelle l'atelier de développement logiciel le plus puissant et le plus facilement adaptable aux autres langages et environnement de développement. Pour preuve le plugin Google s'intègre complétemetn et de manière totalement transparente (CF: le builder DEX par exemple intégré de manière transparente à la phase de compilation). D'autre part, il existe tout une batterie d'outils tout à fait mûrs pour gérer mieux le cycle de développement (Maven, Ant et Continuum par exemple). De plus il faut noter que toute cette toolchain est libre et codée dans un seul et unique langage, ce qui apporte une cohérence à l'ensemble. Pourquoi pas un nouveau langage? La plateforme s'appuie justement sur un succès fort pour attirer le développeur. Pour parler d'un autre point important, il faut souligner la possibilité de tirer parti de manière transparente de librairies pré-existentes: - BouncyCastle pour tout ce qui est cryptage (Déjà compatible J2SE et J2ME) - Les librairies apache: certaines sont directement intégrées (http-client, commons-codec) - Bluez - JSon - KXml pour le suport XML Et pourquoi pas KSoap? Ca serait intéressant pour les accès WS. KSoap repose sur KXml. De plus Google à une culture Java bien encrée: GWT par exemple. A chaque grosse société son langage: - Microsoft => C# - Mac => Objective C - Google => Java, C/C++, Python Google se positionne par rapport à microsoft en choisissant Java. De plus Google a des partenaires de taille dans le monde libre (ou non) qui supportent Java très activement. Les plus actifs étant: Red Hat par JBoss, Sun bien sûr (GlassFish, OpenJDK, ...). Je pense également à IBM et Oracle qui sont très actifs, mais s'ils ne sont pas vraiment sur la brèche du libre. Cependant on notera un point comment entre tous ces acteurs: Ils supportent Linux. J'aurais bien vu une plateforme Flex pour mobile exploitant Flash et l'ActionScript, je suis toujours étonne qu'Abode n'ait toujours pas poussé le concept! Je vois mal adobe rester muet très longtemps en ce qui concerne la mobilité, c'est l'étape suivante après apollo/flex :D
Très intéressant ce parti-pris. Ca ouvre aussi des possibilités pour les développeurs C et C#, dans la mesure où on pourrait imaginer un compilateur Android Bytecode (ou alors développer sur Windows Mobile mais c'est mesquin ^^).
Ce contenu est bloqué car vous n'avez pas accepté les cookies et autres traceurs. Ce contenu est fourni par Disqus.
Pour pouvoir le visualiser, vous devez accepter l'usage étant opéré par Disqus avec vos données qui pourront être utilisées pour les finalités suivantes : vous permettre de visualiser et de partager des contenus avec des médias sociaux, favoriser le développement et l'amélioration des produits d'Humanoid et de ses partenaires, vous afficher des publicités personnalisées par rapport à votre profil et activité, vous définir un profil publicitaire personnalisé, mesurer la performance des publicités et du contenu de ce site et mesurer l'audience de ce site (en savoir plus)
En cliquant sur « J’accepte tout », vous consentez aux finalités susmentionnées pour l’ensemble des cookies et autres traceurs déposés par Humanoid et ses partenaires.
Vous gardez la possibilité de retirer votre consentement à tout moment. Pour plus d’informations, nous vous invitons à prendre connaissance de notre Politique cookies.
Gérer mes choix