Au fil des années, Google a créé sa propre implémentation des API (interface de programmation) Java pour faciliter le travail des développeurs. Si l’implémentation est propre à Google, les API utilisées appartiennent en revanche à Oracle, qui a racheté Sun Microsystems en 2010, et qui sont présentes dans le JDK (Java Developement Kit). Google vient d’annoncer que le code source d’AOSP pour Android N a été revu, afin d’implémenter les API présentes dans OpenJDK, la version open source du JDK d’Oracle, déjà en partie utilisée par Google avec Android.
Une décision pour faciliter le travail des développeurs
Officiellement, Google annonce que ce changement facilitera la vie des développeurs avec une seule base commune d’API : celle d’OpenJDK. Google compte également partager le code source de son implémentation d’OpenJDK au sein d’Android. Google souhaite aussi avoir un plus grand impact sur le développement d’OpenJDK en proposant des fonctionnalités qui pourraient servir à tous les développeurs utilisant cet environnement de développement, et pas seulement sous Android.
La bataille juridique refait surface
Officieusement, la raison pourrait se situer ailleurs. Il existe en effet une bataille juridique entre Google et Oracle depuis 2010 puisque suite au rachat de Sun Microsystems, Oracle réclamait à Google le paiement d’un milliard de dollars de dommages et intérêts. En cause : l’utilisation des API du JDK par Google. Mais pour le géant de Mountain View, les API ne peuvent pas être protégées par le droit d’auteur. Malheureusement, en 2014, un juge américain a décidé que les API d’Oracle pouvaient être protégées par des brevets, donc violées par Google. L’affaire n’est toujours pas close, puisque la Cour Suprême a renvoyé l’affaire à une juridiction inférieure. Le verdict est attendu avec impatience par toute l’industrie, l’impact pouvant être gigantesque sur l’utilisation libre, ou non, des API. En utilisant les API d’OpenJDK, Google est sûr de ne pas violer de brevets.
Quoi qu’il en soit, Android N délaissera donc totalement les API du JDK d’Oracle pour se consacrer aux API d’OpenJDK. Les développeurs devraient y trouver leur compte, tout comme les juristes de Google.
Utilisez-vous Google News (Actualités en France) ? Vous pouvez suivre vos médias favoris. Suivez Frandroid sur Google News (et Numerama).
> Ai je bien compris ? > On peut donc faire breveté une API, c'est à dire une interface ? > Il va y avoir des procès pour les 45 prochaines années, c'est un non sens totale. (citation volontairement améliorée sur le "plan du français") De ce que j'ai compris, Oracle prétend qu'une API est brevetable. Mais à ma connaissance, la justice des USA n'a pas encore tranché. http://arstechnica.com/tech-policy/2015/08/all-android-operating-systems-infringe-java-api-packages-oracle-says/ Si la justice des USA dit "oui", ce serait pour moi également une énorme bêtise, comme les brevets logiciels. Certaines entreprises mettent des brevets des choses qu'elles ont trouvé (ce qui est différent de créer) dans le monde vivant. À cela on peut rajouter les brevets sur les médicaments qui peuvent laisser des traces dans l'organisme et pourquoi pas modifier dans le futur l'ADN ou les cellules utilisées pour la reproduction. Un bébé issue d'au moins une personne modifiée par des médicaments brevetés sera t'il considéré comme une contrefaçon qu'il faudrait détruire au nom des affaires ? Benjamin Bayart à NUMA en 2012 (1h15min pour les questions de brevets) expliquait vite mais bien des implications politiques de ces questions. https://www.youtube.com/watch?v=eKFjW2IqJI4
J'me disais aussi, a peine j'ai lu le titre j'ai pensé au conflit que Google avait eu avec Oracle
Ais je bien compris ? On peut donc faire breveté une API c'est à dire une interface ? Putain va y avoir des procès pour les 45 prochaines années, c'est un non sens totale. Je vais faire breveter l'alphabet latin et les interactions sociales sous n'importe quel forme que ce soit. Le fait de vivre aussi.
La JVM pour être performante doit faire de la compilation dynamique (JIT) ce qui est interdit sur iOS. En plus son evolution depend d'un autre que Google. La "voie" qu'a trouvé Google semble être Flutter (voir flutter.io). Google n'est pas dans une logique d'enfermement des devs dans Android. Ils sont pour du multiplateforme et l'ont toujours été. Ce qu'ils souhatient c'est de la simplication: le meme code pour toutes les plateformes. Meme si Android esst important pour Google, ca l'est moins que mainternir les produits Google (search, gmail, maps, etc) présents sur toutes les plateformes qui comptent. Ce n'est pas le meme logique qu'un Apple ou un Microsoft.
Dans l'absolu, la JVM est déjà ce que tu qualifies, je pense, de "runtime". Il est tout à fait possible de compiler autre chose que du Java vers du bytecode Java. C'est ce que fait Scala, par exemple. Ce dernier peut être compilé à destination d'une JVM, ou d'un runtime .NET. Le problème d'un langage multi-plateformes ciblant à la fois Android et iOS, c'est qu'un développeur formé pour Android peut très vite basculer côté iOS. Et ça, c'est pas intéressant pour Google… Un rapprochement entre Android et Chrome OS, oui, pourquoi pas, par contre. Comme tu dis, à suivre !
Pour moi c'est le signe qu"ils vont mettre Java au second plan et promouvoir des alternatives a Java pour developper sur Android. Idealement,pour Google, une alternative multi-plateforme ciblant Android et iOS. Une grosse partie des equipes affectées a Chrome travaillent depuis plusieurs mois sur des projets dans ce sens notamment autour de Dart. On sait aussi que des travaux de rapprochement entre ChromeOS et Android sont en cours. Je ne serais pas surpris d'une annonce prochaine a ce sujet ou Java passserait en second plan. Idealement un runtime plutot qu'une language d'ailleurs, laissant ainsi le choix aux developeurs d'utiliser le language qu'ils preferent et capable de cibler 'Android, iOS et ChromeOS (directement ou via du javascript multi navigateur). a suivre
> légal, donc, ce n'est plus Google qui implémente les API potentiellement brevetées mais Oracle directement via son OpenJDK Le fait de faire une implémentation n’est pas un problème pour la justice USA. Du coup, Oracle se bat pour faire en sorte que les API (nom des classes, méthodes, paramètres, types de retour, etc) soient reconnus comme soumis au droit d'auteur et/ou aux brevets ! > ça risque de finir en fork un jour ou l'autre (si la licence le permet) OpenJDK est sous GPLv2+. http://openjdk.java.net/legal/ De plus, c'est inclus dans le dépôt main de Debian, donc la licence et les exceptions sont conformes aux DFSG, ce qui implique qu'il est légal de forker. https://packages.debian.org/stretch/openjdk-8-jdk https://www.debian.org/social_contract#guidelines Sinon ça explique très bien le reste.
J'ai bien ri, merci.
Je vois, merci. :)
À moins d'utiliser une application développée avec les pieds (faut vraiment y mettre de la mauvaise volonté, côté dev', pour en arriver là), et peut-être une très, très légère différence de performances (sans doute absolument pas perceptible), aucun.
Je ne vais pas parler du plan légal, sur lequel vous êtes sans doute mieux informé que moi, mais sur le plan technique, cet article est un brin erroné. Google n'implémente pas les API d'OpenJDK. Les API d'OpenJDK, celles du JDK Oracle et celles actuellement implémentées par Google sur Android sont identiques. Une API n'est que le "contrat" à respecter par le code qui l'implémente. Les différences entre les trois (Google, Oracle et OpenJDK) sont au niveau des implémentations qui sont faites des API. En utilisant l'OpenJDK plutôt que sa propre implémentation, Google a différents intérêts : - légal, donc, ce n'est plus Google qui implémente les API potentiellement brevetées mais Oracle directement via son OpenJDK - commercial, leur implémentation n'est plus à maintenir (mais l'intégration d'OpenJDK n'est pas gratuite pour autant, niveau boulot) - pratique, leur implémentation étant régulièrement en retard sur OpenJDK ou le JDK d'Oracle (elle ne supporte pas encore Java 8 par exemple). Mais il y a aussi des risques et inconvénients : - ils ne maitrisent plus la direction que prend l'implémentation, ça risque de finir en fork un jour ou l'autre (si la licence le permet) et de revenir à la situation actuelle - leur implémentation était peut-être optimisée spécifiquement pour Android et les terminaux sur lesquels ce dernier tourne, ce qui ne sera plus le cas avec OpenJDK Grosso-modo, à part en interne chez Google, et chez Oracle, ça ne changera rien. Les quelques développeurs qui comptaient sur des détails d'implémentation réalisés par Google (s'il y en a) auront certes un peu de boulot, mais ils en sont les seuls responsables…
Oracle, cette boite de mort la faim, qui souhaite breveter de API de dev, c'est juste n'importe quoi.
Quels en seraient les impacts pour l'utilisateur final ?
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