Google travaille actuellement sur un remplacement de ses API Java. Selon l’éditeur, la prochaine version majeure d’Android, simplement baptisée « N » pour l’instant, se baserait sur l’implémentation OpenJDK pour simplifier le travail des développeurs. Cependant, les retombées juridiques pourraient avoir été un puissant moteur de cette décision.
C’est par un « commit » dans le code d’Android que certains ont remarqué que 8 092 fichiers avaient été modifiés et faisaient clairement référence à OpenJDK, l’implémentation libre de Java proposée par Oracle. Rappelons que ce dernier a racheté Sun en janvier 2010, récupérant du même coup la technologie Java. Or, il y a deux implémentations : OpenJDK, qui constitue le socle open source, et Oracle JDK, son implémentation commerciale, considérée comme plus stable.
Interrogée par Venture Beat, Google a confirmé qu’une transition vers OpenJDK était bien en cours. Pour la société de Mountain View, les développeurs devraient voir leur travail simplifié, puisqu’il n’y aurait alors plus qu’une seule base de code pour l’ensemble des API. Par ailleurs, l’éditeur a affirmé que l’arrivée de la version commerciale Java 8 et de ses multiples améliorations était une grande motivation pour se tourner vers OpenJDK et s’y investir. En clair, le mouvement de Google serait fait pour le confort et le bonheur des développeurs.
Google, Oracle et un long procès autour de la propriété intellectuelle
Seulement voilà, ceux qui connaissent l’histoire de Java savent qu'elle a été marquée par une tension juridique intense entre Google et Oracle. Dès 2010, ce dernier avait déposé une plainte pour violation de copyright sur un lot de 37 API de Java, utilisées directement par Google pour concevoir sa machine virtuelle Dalvik, au cœur d'Android jusqu'à fin 2014. Le géant de la recherche avait nié dans un premier temps cette violation, avant de la reconnaître en partie. Mais un premier juge avait déclaré en 2012 que ces API ne pouvaient en effet pas être protégées par le copyright, car Google n'avait finalement que gardé les noms des méthodes, tout en changeant la quasi-totalité du reste.
Après coup, la course des évènements s’est cependant inversée pour Google. En 2014, une cour fédérale d’appel a déclaré en effet que les API de Java pouvaient être « copyrightées » et qu’Oracle était donc parfaitement en mesure de réclamer des royalties à Google pour les avoir utilisées. Depuis, et alors que la Cour Suprême a refusé de s'occuper de cette affaire, Google essaie de faire valoir que même si Dalvik utilise des technologies reconnues comme protégées, il s’agit d’un cas typique de « fair use ». Autrement dit, ces technologies sont si répandues qu’Oracle ne devrait pas en réclamer autre chose qu’une somme symbolique. Une décision qui pourrait faire jurisprudence sur l’utilisation des API en général.
Dalvik dans un premier temps, les API dans un second
La machine Dalvik avait été faite initialement pour permettre la création rapide d’applications via un langage de haut niveau. Parallèlement, Google l'avait proposée pour disposer d’une machine virtuelle Java qui serait orientée vers l’univers mobile et ses contraintes propres. Après tout, un smartphone n’a pas la puissance d’un PC ou d’un Mac, et les premiers terminaux mobiles sous Android n’avaient clairement pas les performances de ceux d’aujourd’hui.
Avec Android 5.0, Google s'est pourtant débarrassé de Dalvik, pour la remplacer par une nouvelle machine virtuelle, cette fois totalement réalisée en interne : Android Runtime, ou ART. Ce dernier apportait notamment plusieurs avantages techniques, en particulier la compilation ahead-of-time pour améliorer les performances, jugées précédemment médiocres. Elle avait également le mérite de ne plus pouvoir être attaquée sur le terrain de la propriété intellectuelle. Cela étant, ce changement ne réglait pas toute la question.
Le travail continue en attendant la présentation d'Android 7.0
Google travaille donc depuis plusieurs années au remplacement de tous les éléments « incriminés » de Java. Mais si cette bascule progressive pourrait soulager la pression juridique, cela ne résoudra pas tout le problème : seul Android 7.0 et les versions ultérieures bénéficieront de la nouvelle implémentation OpenJDK, laissant toutes les autres moutures avec les anciennes API. Le combat contre Oracle s’appliquerait donc toujours pleinement, surtout quand on connait la vitesse de mise à jour des smartphones Android vers une nouvelle version majeure du système.
Le travail va donc continuer sur les changements de code. Android 7.0 ne devrait de toute façon pas être présenté avant plusieurs mois, pour une arrivée de la version finale à l’automne, comme d’habitude. Il n’est pas dit non plus que les applications actuelles puissent fonctionner correctement sans le moindre changement, mais Google devrait communiquer sur ce point le cas échéant.
Commentaires (97)
super bientôt plus de java ni de flash.
Ça ne changera rien juridiquement puisque OpenJDK se base sur les API de Java 8 et Oracle fait un procès non pas parce que Google aurait copier du code de Java mais parce que Google utilise une de leur API comme tu le dis à la fin de ton premier inter-titre.
Sinon les 2 du dessus vous n’avez pas vraiment compris la news à priori.
pyro-700 et maxscript : Déjà vous faites un amalgame entre le plugin JAVA (pour les applets, truc qui effectivement est dépassé) et le langage JAVA lui même. Et comme dit par Soltek vous n’avez pas bien saisi le contenu du la news.
De ce que je comprend de la source, Android ne va plus s’appuyer sur les API commerciales mais seulement celles proposées par openJDK. Google devrait aussi participer d’avantage à openJDK en laissant plus ou moins tomber sa propre implémentation complète.
Google fera sa propre implémentation en intégrant OpenJDK.
Bon, autant la faire courte : java ≠ javascript
Et Java est l’un des langages, avec le C (C++…), le plus utilisé au monde.
Merci et au revoir
Merci aux INpactiens de ne pas considérer Java uniquement pour les (dépréciés) applets.
Je pense que vous ne vous rendez pas compte de la qualité de matériels et services basés sur ce langage et ce runtime que vous utilisez (sites, téléphones, équipement multimédia…) et qui seraient impossibles ou autrement plus compliqués ou plus chers à mettre en oeuvre dans d’autres technologies.
Me font toujours marré ceux qui veulent la mort de Java, ils ont souvent jamais touché une ligne de code de leur vie et ne savent finalement pas quoi ils revendiquent.
" />
" />
Le rachat de Sun par Oracle leur a permis une intégration verticale de leur solution (ils avaient le soft & ils ont acheter le hard). Sun était un «gentil» et pas trop regardant sur l’utilisation de leur technos logiciel, Oracle est tout le contraire.
Le troll était évident, il ne fallait pas y répondre ;)
Quand je vois comment çà dérape sur le sujet du viol présumé, et le swordage massif ici alors que juste le premier message était un troll mais le reste était censé…
Oui sauf que comme je le dis justement dans le commentaire que tu quote, le 2nd procès ne parle pas du code mais de l’API directement.
Ca saque ferme dans les comments ici
" />
Comme expliqué mille fois, le commentaire supprimé entraine avec lui tous ceux qui le citent.
Ah bon? Tu veux dire que le “Réponse à un commentaire supprimé” n’est pas une mauvaise excuse du censeur pour les massacres à la machette qu’il a la flemme de justifier?
" />
Du coup, je me demande vraiment comment on peut à la fois breveter des API et proposer un JDK open-source qui reprend exactement lesdites API.
Un tel paradoxe met bien en lumière l’aberration, voire la stupidité, de la brevetabilité des API…
Si il y a un dev qui passe par là, concrètement les API changent beaucoup entre celles d’Oracle et celles d’OpenJDK ? Je suis pas dev mais je vois comment ca marche dans d’autres langages, mais le java je n’ai jamais touché…. (seulement .Net - oui je sais c’est mal - et C++ en dilettante sur du Qt, ou les vieilles saletés qu’on apprend à l’école, Delphi Windev TPascal et compagnie)…
Il est probable qu’il faudra recoder une partie des anciennes applis écrites avec le JDK Oracle pour qu’elles tournent sur droid v7 ou pas ? On parle de quoi là ? De fonctions / classes différentes dans les API des deux JDK ? De traitement différent en interne des mêmes fonctions / classes en interne avec des appels similaires ?
Edit : OK, vu au dessus. Puisque l’OpenJDK est open justement, ce ne serait pas aberrant qu’Oracle en ait implémenté une bonne partie chez lui.
Donc risque de pertes de fonctionnalités spécifiques à Oracle.. Ou même implémentation modifiées des méthodes venant d’OpenJDK…
Bref à suivre, mais ca me semble chaud comme transition au 1er abord…
est-ce un signe que Google va bientôt reléguer Java au second plan pour Android ?
En //, leur projet Flutter (voir flutter.io) avance vite. On se demande ce qui se prépare la.
Java par Jetbrains, c’est au top !
“surtout quand on connait la vitesse de mise à jour des smartphones Android vers une nouvelle version majeure du système”
mdr
Android 7… alors qu’une majorité de terminaux seront encore à la version 4….
" />
Lorsque le montre la version 6 de mon Nexus6 Moto les gens écarquillent les yeux comme face au Saint-Graal
Moi y a plein de gens qui ne sont même pas au courant qu’elle existe.
" />
Bon j’ai failli poster mais après j’ai lu la source :p
A voir ce que donne réellment openjdk en terme de performance et de stabilité sur android, les retours ont quand même pas l’air top…
Je veux dire à part frimer devant les filles en leur racontant comment on est un vrai, un dur.
Mouais enfin bon…. avec les brevets logiciels Oracle a moyen d’attaquer à nouveau Google parce qu’il utilise OpenJDK qui utilise des trucs Oracle. Ce serait pas mieux de juste utiliser autre chose ?
Je me retiens fortement de troller sur Java mais c’est un truc loin d’être indispensable un, la preuve y’en a pas sur les Windows Phone.
Personnellement, j’ai réellement commencé la programmation avec le C (avec un peu de Pascal quelques années auparavant). C’est parfait pour apprendre la gestion de la mémoire et largement assez bas niveau pour débuter. Plonger les mains directement dans de l’assembleur n’aura pour seul résultat que d’embrouiller un débutant.
Sur Windows Phone il y à l’environnement .NET qui est soumis au même contraintes que Java, je ne vois pas pourquoi Google souhaiterait cesser les hostilités avec Oracle pour les recommencer avec Microsoft.
Le problème ici n’est pas avec Java SE ni avec .NET, le problème ce sont les brevets logiciels.
En développement il n’existe pas forcement 36 implémentations différentes de la même chose, surtout lorsque l’on doit respecter des spécifications bien précises.
Google à fait dans Dalvik ce que Sun avait fait dans HotSpot parce qu’il n’existe pas d’autres moyens efficaces de le faire, leur demander de faire autrement aurait été aussi con que de leur demander de trouver une nouvelle implémentation au quicksort. Sauf que dans le cas du quicksort un algo n’est pas brevetable, alors que dans le cas du code “ça dépend”, cette situation n’est pas tenable et tant mieux si le procès Google/Oracle peut faire jurisprudence une bonne fois pour toute car l’exception Américaine sur la légalité des brevets logiciels est étouffante pour tout le secteur.
Java c’est le diable.
Vivement sa disparition.
Dommage qu’Android se soit basé dessus, ses performances seraient 2x meilleures en C++ plutôt que cette ignominie de Java qui disparaîtra bientôt aux fonds des chiottes de l’histoire informatique.
try {
Hahahahaha!!! Les gens trollent vraiment sur n’importe quoi! Si au moins il le faisait avec subtilité…même pas!
Toi tu n’as jamais travaillé avec des débutants en informatique.
Quand un développeur fait une erreur car il ne comprend pas ce qu’est une reference a cause d’une école qui n’enseigne que JAVA (et en aucun cas le fonctionnement de la machine en dessous) tu comprend que la vision des années 1990 était la bonne.
J’ai appris java mais ensuite (enfin en même temps) j’ai appris le et et l’assembleur pour comprendre ce qu’il se passe. Je serais incapable de coder dans ces langages mais les notions que j’ai me permettent de pas faire trop de conneries avec les langages de haut niveau (et ça permet des optimisation plutôt sympa que tu ne peux pas faire sans comprendre comment ça marche)
désolé pour mes camarades… je ne souhaitais pas troller et emporter une cordée de comm avec moi ;)
java c’est bien java c’est bien java c’est bien.. (bon ok même comme ça, ça passe pas), mais chacun ses outils de prédilection on va dire….
Ah, Android va migrer vers Bada! (oui,
" /> honteux, mais j’assume avoir apprécié l’utilisation de cet OS)
Apprendre l’assembleur n’est pas utile. La théorie suffit.
J’ai l’impression que ceux qui disent qu’il faut apprendre l’assembleur veulent seulement se venger d’avoir été forcé de l’apprendre. Un peu comme un bizutage, en fait.
Hé bien je ne suis pas d’accord avec toi.
J’ai travaillé sur tout type d’application, du DVD-Interactif codé en Javascript + Assembleur au simulateur 3D temps réel en passant par de la GMAO, de l’application web et de l’application desktop. Et un soupçon de développement mobile.
au gré de ces expériences, je te rejoins sur le fait que savoir comment ça marche dans les basses couches peut être dans certains cas utile, mais c’est loin d’être systématiquement vrai.
Conseiller de commencer la programmation par l’assembleur : non.
Conseiller de commencer par apprendre de bonnes méthodes de travail : oui.
Si aujourd’hui je fais une application web en PHP/Angular.js, l’assembleur je m’en contrefout par contre
savoir déboguer mon code client dans un navigateur : indispensable
comprendre comment le navigateur interprète mon code .js : indispensable
comprendre les spécificités de l’exécution asynchrone : indispensable
savoir brancher un débuggeur sur mon code PHP pour voir ce qui se passe lorsque le code serveur est exécuté : indispensable
Tout le code que l’on écrit n’est pas directement converti en langage machine comme dans le cas C,C++/assembleur.
Et l’intérêt de savoir comment mon serveur PHP lit mon code, le transforme en langage machine puis comment ce langage machine s’exécute, même si j’en comprends l’intérêt, je ne le donnerai pas en prérequis à l’apprentissage de la programmation mais plutôt comme un approfondissement de cette compétence, quelque chose qui permet de faire la différence entre un débutant et un lead technique par exemple.
Disons pour faire simple que les connaissances théoriques ne servent à rien sans les bonnes méthodes et les bons outils de travail.
C’est justement le mot-clé : la théorie.
Si tu sais comment un processeur gère la mémoire de manière théorique, l’assembleur ne ferait que confirmer par la pratique ce que tu sais déjà. Mais tu peux aussi le faire avec C, Ada ou Pascal. L’assembleur en particulier n’est pas plus utile que ces autres langages un peu plus haut niveau. Ce qui est utile est la théorie. Et ce n’est pas parce que certains apprennent par la pratique, auquel cas l’asm est effectivement le plus efficace, que ça en devient une généralité.
Traduction foireuse. Un projet en C ne répondra pas aux même besoins qu’un projet en Java, et inversement.
" />
Je t’invite par exemple à réaliser en C une application distribuée sur des serveurs d’applications, avec interfaces web et/ou mobiles, gestion de la généricité et sans ce que le développeur n’ait à s’occuper de la mémoire ni de recompiler le projet selon la plateforme.
Tu vas vite te rendre compte que .Net et Java sont les environnements les plus adaptés.
Pour ma part j’irai plutôt prendre du C pour de l’embarqué, pour un développement rapide avec utilisation d’API systèmes, etc.
Après tu voulais peut être parler du C++ qui même des avantages des deux (POO et accès système), mais toujours pas adapté pour l’exemple que je viens de donner.
Tu peux donc ranger ton troll.
P.S. J’en profite pour corriger une erreur de typo dans mon 1er message, où j’ai écris “qualité” au lieu de “quantité.
Et troll-poof : la qualité du code n’est pas inhérente au langage mais aux développeurs. ;)
C est un très beau langage compilé.
C++ c’est un langage dégueulasse mais avec une notion d’objet, permet de faire tout et n’importe quoi, mais surtout n’importe quoi n’importe comment, massivement utilisé. Mais c’est toujours du compilé.
Ces précédents 2 langages sont effectivement plutôt efficace du fait de leur compilation et optimisation, mais la vitesse de programmation est très lente. Du coup, ils ont une utilité lorsque le besoin de performance se fait ressentir.
De ce fait, à coté, il y a des généralement codes universelles offrant des possibilité diverse et varier, simple d’accès (sans prise de tête avec la mémoire) avec une bibliothèque de base généralement assez bien fourni.
Python, est un langage pratique pour faire des petits truc rapide sans prise de tête. L’écriture est efficace mais l’écrit peut être dégueulasse. Code normalement portable sur la plupart des plateforme.
Javascript, du peu que j’ai utilisé, j’ai un ressenti assez négatif, assez bordélique et possède aussi le même problème que python. Cependant, théoriquement code universel dès lors qu’il existe un navigateur (qui l’interprète bien)
Et Java qui contrairement au 2 précédents à choisi de garder le coté très strict des langages compilés sans la prise de tête de la gestion de la mémoire. Java à fait aussi le choix d’un objet assez fort, du coup forçant à faire de l’objet pur.
Du coup, je trouve que java fait un très bon compromis pour faire des gros projets (garder un code acceptable) mais de l’autre arriver à cracher du code qui tourne assez rapidement.
Sinon, pour le problème de performance, La différence reste généralement à peut prêt proportionnelle entre les différents langage quelque soit le programme or la loi de Moore est exponentielle, du coup, c’est pas forcément intéressant de faire quelque chose de performant car de toute façon dans 1ans, les terminaux seront capable de le faire tourner dans le langage “moins bon”. En conclusions, utiliser des langages compilés n’a d’intérêt que lorsque que l’on est dans la recherche de performance (système, bibliothèque graphique, calcule intensif…). Pour le reste, un langage “haut niveau” est largement suffisant.
J’entends quelqu’un parler de langage fonctionnel ? aucun intérêt… si faire des preuves… mais personne ne prouve.
Je peux compléter sur js et python (que j’utilise tout les jours)
-Js seul est inadapté pour des gros projets, c’est vite le bazar mais il existe des outils pour remédier a ce problème. Son principal defaut est qu’il ne contraigne pas le dev et donc si ces derniers manquent de rigueur le code sera impossible a maintenir.
-Python marche aussi pour des projets de taille moyenne (quelques dizaines de milliers de lignes) il permet d’écrire bien plus vite que java et en beaucoup moins de ligne (au bureau en 10 000 ligne j’ai un SI qui en fait bine plus que 30 000 ligne en java) mais est (beaucoup) moins performant et comme le JS il fait confiance au développeur pour pas faire n’importe quoi. Encore une fois c’est pas adapté au monde des SSII ou on considère que chaque développeur est interchangeable avec un autre moins cher
Et tout cela reste encore à relativiser par les accès base de données. C’est bien joli d’avoir un langage super-optimisé-de-la-mort-qui-tue, mais dans une majorité d’applications “business” ça reste bien les accès base de données qui sont le facteur limitant. Même si on arrivait à optimiser la boucle de chargement des données à un unique REP STOSW en assembleur, on ne gagnera pas grand chose vu que le serveur a dû consulter les index, rechercher dans les caches, lire des blocs, assembler les données, etc. L’impact en performances d’utiliser un langage “moins efficace” pour parcourir les records une BDD s’efface par rapport à la simplicité d’écriture.
Par ailleurs, les langages fonctionnels sont très pratiques pour décrire des bases de règles et des validations de données (si la facture contient au moins trois produits du rayon brico, alors le taux de TVA est de 6%), beaucoup moins pour faire du transactionnel. Le grand avantage est que l’absence d’effets de bord fait que … hé bien un calcul ne peut pas avoir d’effet de bord, justement, et donc compromettre l’intégrité d’autres données. Très pratique quand c’est l’utilisateur final qui peut spécifier ses règles.
et personne pour défendre rust et go dans vos débats :(
Je veux bien défendre Rust (J’aime bien ce langage), et Go( un bon langage pour “pisseur de code en SS2I”) mais personne n’en a encore dit du mal.
personne n’en a rien dit :)
en fait, j’ai cru voir certains dire que le C/C++ serait l’éternel champion, mais j’émets de gros doute là dessus
non pas que je pense qu’il disparaisse, mais sa popularité pourrait baisser plus vite qu’on ne le pense, et, selon moi, rust et go sont les langages qui vont lui prendre le plus de part (dans des catégories différentes)
Encore plus court :
C != C++
Python, est un langage pratique pour faire des petits truc rapide
sans prise de tête. L’écriture est efficace mais l’écrit peut être
dégueulasse. Code normalement portable sur la plupart des plateforme.
quand
tu codes dans un langage depuis plus d’unb an, peu importe son nom, ce
que tu dit est vrai : tu codes vite, tu es efficace mais tu peux
rapidement faire du code crade.
Et a priori, le code python étant
100 fois plus expressif que les autres, j’ai tendance à penser qu’il
est bien plus propre qu’un code java farci d’antipattern.
Et Java qui contrairement au 2 précédents à choisi de garder le
coté très strict des langages compilés sans la prise de tête de la
gestion de la mémoire. Java à fait aussi le choix d’un objet assez fort,
du coup forçant à faire de l’objet pur.
le concept “objet” est plus fort et mieux intégré en python (ou mieux en C#) qu’en java tu sais.
J’entends
quelqu’un parler de langage fonctionnel ? aucun intérêt… si faire des
preuves… mais personne ne prouve.
un des plus gros
utilitaires de conversion de format, pandoc, est en haskell, et utilise à
mort les concept du langage, Monade y compris… Donc raté.
PS :
par honnêteté, je suis issu du monde PHP, et j’ai évolué vers .NET
(C#et un peu F#) et python pour lequel je fais autant du scripting que
du web (django, pour Ce projet (site web))