Oracle est en perte de vitesse car ils n'ont pas pris le virage technologique NoSQL, ni le virage BigData, ni celui du Cloud.
Microsoft veut prendre des parts de marché et brade le prix de sa solution SQL Server associée à son cloud Azure.
Oracle ne peut suivre au niveau des tarifs car c'est sa principale source de revenus. Oracle est en train de payer sa politique de recherche du profit en délaissant le Customer Care et donc en délaissant l'innovation.
Dans le pays aux brevets logiciels, les patrons ont tendance à penser que recruter une armée de juristes+avocats rapporte plus qu'une armée de développeurs… Par exemple, le procès Oracle-Google concernant la réutilisation de l'API de la JVM par Android.
Du coup, Oracle cherche à faire fructifier ses actifs. Ils auraient pu proposer une version payante de OpenOffice à côté de la version gratuite, mais ils sont tellement mauvais qu'ils ont perdu la maîtrise de ce projet libre.
Et que pourrait faire Oracle avec sa pépite Java ? Augmenter la cadence de livraison des nouvelles versions, donc de réduire la période gratuite de maintenance (correction des bugs).
Cela concerne Java, mais aussi toutes les technos qui utilisent la JVM : Groovy, Scala, Kotlin, Jython…
Mais les entreprises apprécient la stabilité, ne pas changer les versions des JVM tous les xx mois quand la Prod fonctionne correctement. C'est justement là l'astuce d'Oracle : vendre l'extension de garantie. Un peu comme Microsoft, qui s'en ait mis plein les poches avec la fin de la prise en charge (support) de Windows XP.
Pour Java 8, ça se termine dans moins de trois mois ! Que va dire l'équipe InfoSec ?
Le concurrent Azul veut saisir l'opportunité pour vendre sa JVM Zung.
https://www.azul.com/products/zing/zinqfaq/#whatzingcost
Le prix : 3500 $ par serveur avec autant de mémoire et de core que l'on souhaite (prix négociable). Ce tarif incite à utiliser de grosses machines 256 cores physiques, 2 To de RAM, des SSD eMV (tarif à 5 chiffres).
Cela permettrait d'y faire tourner une partie de la Prod, en utilisant le cgroup pour confiner les process. Compter au moins deux licences (machines) pour la haute disponibilité.
Cette JVM n'est malheureusement pas libre. Mais de nombreuses entreprises ne sont pas sensibles à cet argument et préfèrent comparer au nombre de jour·personne que cela pourrait faire économiser/perdre. Avec 500 $ par personne et 2 machines, la licence Zing correspond à une quinzaine de jours·personne (3 semaines·personne).
Et si cette JVM de course augmentait tellement les performances des applications que son coût serait inférieure au temps nécessaire à optimiser le code ?
…ou au contraire, l'application tournerait trop vite et révélerait des bugs auxquels il faudrait passer du temps à les corriger…
(écrit sur mon mobile avec Firefox)
# Une heure pour la rédaction
Posté par Oliver (site web personnel) . Évalué à 2.
J'ai mis une heure pour la rédaction sur smartphone de cet article (460 mots).
Comme c'est fastidieux, on passe peu de temps à vérifier/sourcer ses propos.
Un amis m'indique que j'ai oublié Clojure comme langage JVM (j'ai aussi oublié JRuby).
Voir la liste sur Wikipédia : https://en.wikipedia.org/wiki/List_of_JVM_languages
Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
[^] # Re: Une heure pour la rédaction
Posté par barmic . Évalué à 10.
Tu as surtout omis OpenJDK de ton analyse…
Le JDK Oracle est une distribution d'OpenJDK. Il en existe 2 autres assez connues : celle de RedHat et celle d'IBM. Ces derniers ont des supports déjà plus long que ce que permet Oracle. Mais surtout l'air post-JDK8, s'annonce très chamboulé. Le projet adopt OpenJDK est une distribution libre de ce dernier. Il est soutenu par des entreprises tel qu'IBM. Et devrait intéresser quelques acteurs par exemple avec leur API simple REST et documentée pour récupérer un JDK. IBM semble particulièrement investi vu que l'on peut y trouver une version avec leur gc maison.
Après pour faire tourner une prod, je ne vous pas ce que la distribution d'Oracle apporte (pour les dev il y a des outils qui peuvent être utiles sans pour autant être nécessaires).
Les entreprises beaucoup n'ont pas la vision de ce qu'est un runtime pas à jour et font tourner du java7 ou inférieur. Ça ne changera rien pour eux. Pour les logiciels un minimum maintenus le passage à jigsaw n'est pas insurmontable.
Je n'aime pas particulièrement Oracle, mais dire qu'ils font ces changements juste pour diminuer la période de maintenance c'est aller un peu vite. Ils ne sortirai pas une version tous les 6 mois, mais ce contenteraient de la version tous les 18 mois (LTS). Ce serait bien plus simple.
Je ne suis pas qu'Oracle est un saint et qu'il n'y a rien à regarder, mais qu'il faut garder la tête froide et s'intéresser à ce qui se passe aussi dans les communautés avant de crier au loup.
[^] # Re: Une heure pour la rédaction
Posté par Tonton Th (Mastodon) . Évalué à 10.
Tu veux dire qu'il y a de la turbulence dans l'ère ?
[^] # Re: Une heure pour la rédaction
Posté par Le Pnume . Évalué à 3.
Oracle aurait pu faire de l'argent avec R mais MS l'a précédé, toutefois Larry Ellison, n'est pas un pauvre hère.
[^] # Re: Une heure pour la rédaction
Posté par YBoy360 (site web personnel) . Évalué à 0.
Moi j'aurais pas mis ces langages pas comme "technologie java", mais juste comme langages justement..
Les technologies java, c'est plutôt xtext/xtend, MPS, eclipse, Intellij , la notion de containers … Ça, ce sont des technologies.
Il y a certaines limites aux technologies Java qui sont dû aux spécifications de la JVM, mais c'est un autre débat.
# Argument fallacieux
Posté par Pinaraf . Évalué à 10.
Marmotte + chocolat + aluminium…
Aucune JVM, aucun compilateur au monde ne saura lutter contre le bâclage du développement.
Je vais prendre un exemple tout simple où je ne vois pas comment un outil aurait pu corriger le soucis. C'était il y a quelques années, je travaillais sur un interpréteur (très) mal codé pour un langage basic-esque quelconque (j'insiste sur la deuxième syllabe). Un bytecode était généré en mémoire, puis exécuté dans plusieurs threads en même temps (avec des données différentes). Et le temps d'exécution était linéaire avec le nombre de threads. 1 thread − 10 secondes, 2 threads − 20 secondes, 3 threads − 30 secondes (véridique).
Après quelques heures d'analyse, j'ai trouvé qu'à chaque exécution d'une instruction du bytecode, un lock était pris sur un tableau partagé entre tous les threads. Il a suffit de s'assurer que le tableau soit en lecture seule pour tout le monde pour supprimer le lock et avoir un temps linéaire, mais dans le bon sens.
Je n'ai pas fait de Java depuis trop longtemps pour donner des exemples concrets de synchronized et cie, mais ce genre de situation est bien trop courante et surtout hors d'atteinte des VMs ou des compilateurs. Quand bien même tu prouvais que la variable est effectivement bien en lecture seule passé un certain point, c'est un prédicat trop fragile s'il n'est pas garanti par le code, sinon les performances seront aléatoires : un petit changement casse cette optimisation et c'en est fini.
Et quand bien même cette VM était magiquement rapide… la JVM de base est déjà hyper optimisée mine de rien, je serais vraiment surpris de voir une différence de perfs qui soit significative. Certes c'est beau de dire «on utilise LLVM ça poutre sa race», mais la JVM a eu des années d'optimisation que le mode JIT de LLVM n'a pas eu (et pour l'avoir utilisé, c'est vraiment pas dans l'esprit de LLVM le JIT, j'en ferai un journal à l'occasion). Donc où sont les chiffres ?
[^] # Re: Argument fallacieux
Posté par Starch . Évalué à 4. Dernière modification le 21 août 2018 à 10:25.
Je ne connais pas l'ensemble de l'industrie, mais dans mon cas—où le code n'est pas trop bâclé de base—le gros du travail d'optimisation ce n'est pas tant sur le temps d'exécution du code mais sur la limitation du garbage pour empêcher au maximum le GC de se déclencher et stopper le process pendant 10s. Une grosse source de garbage au début était… les logs.
Alors certes le temps d'exécution a son importance, mais le gros problème est surtout le JIT qui ne permet d'atteindre le temps optimal qu'au bout d'un certain nombre d'itérations. Idéalement il faudrait donc préchauffer la JVM pour que les premiers appels ne prennent pas 400ms et les suivants 2 ; et que tous les appels prennent 2ms.
Ces deux problèmes (temps de pause et warmup) c'est vraiment quelque chose qu'une JVM magique peut significativement changer. Alors j'imagine qu'il ne faut pas jeter les JVM alternatives à la poubelle sans avoir testé dans son cas particulier (et les chiffres dépendent probablement de l'application testée).
L'argument original reste bancal à mon sens, la perf c'est un process en soi : il faut se donner des objectifs, les tester régulièrement pour vérifier qu'un changement dans le code ne le casse pas, etc. donc ça a un coût permanent, quelque soit la jvm utilisée.
[^] # Re: Argument fallacieux
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
Faire du warmup avant de lancer l'interprétation, c'est un peu contradictoire avec vouloir faire du JIT, quand même.
L'idée du JIT, c'est de pouvoir profiler le code et prendre des décisions à la volée. Genre si y'a un if() qui n'est que très rarement exécuté, le remplacer par un traitement similaire à celui d'une exception.
Sinon, tu fait une bonne vieille étape de compilation au démarrage et on en parle plus.
De mémoire, la VM .net de microsoft a un cache disque du code compilé/optimisé par le JIT, donc c'est vraiment seulement le tout premier lancement de l'appli qui est lent.
Et d'autre part, je suis surpris qu'on trouve encore des garbage collectors "stop the world". On sait faire des trucs qui tournent en tâche de fond sans avoir besoin de geler complètement le programme, non?
[^] # Re: Argument fallacieux
Posté par xcomcmdr . Évalué à 2.
Ça s'appelle les native images, et on peut demander à ngen de les précompiler à l'installation de l'appli depuis au moins .NET 2.0 (2003).
https://docs.microsoft.com/fr-fr/dotnet/framework/tools/ngen-exe-native-image-generator
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Argument fallacieux
Posté par Dabowl_75 . Évalué à 2.
G1GC ?
[^] # Re: Argument fallacieux
Posté par G.bleu (site web personnel) . Évalué à 4. Dernière modification le 21 août 2018 à 13:51.
Je suis très preneur d'un journal sur LLVM orienté JIT !
Les p'tits gars de Godotengine (moteur de jeu opensource) sont en train d'évaluer le coût d'un JIT pour leur langage de script custom (https://github.com/godotengine/godot/issues/5049) et LLVM semblait la solution la plus pérenne mais malgré tout assez lourde à maintenir.
Oui ce post est HS ;-)
[^] # Re: Argument fallacieux
Posté par Pinaraf . Évalué à 10. Dernière modification le 22 août 2018 à 17:31.
J'aurais mieux fait de fermer ma gueule :)
Ça viendra, mais faut d'abord que je fasse tout un gros dev avec une vraie bibliothèque de JIT pour comparer proprement. Du coup ça va être long. Le cœur du problème pour les cas que j'ai vu : le code est émis en une seule fois (lourdement), et jamais revu après. Et je suis tombé sur au moins un cas où une phase d'optimisation indispensable pour de bonnes perfs est dans l'étape de codegen, qui n'est pas configurable.
Dans le cas qui m'intéresse, PostgreSQL 11, je suis convaincu de l'utilité du JIT par LLVM pour les grosses requêtes où le gain CPU va exploser le temps de compilation requis, mais je suis certain que ça sera en dessous des performances d'un vrai compilateur à la volée, et même dans certains cas en dessous des performances de PG sans compilation (cf. http://www.postgresql-archive.org/PATCH-LLVM-tuple-deforming-improvements-td6029385.html par exemple). Par contre, une solution bien plus légère de compilation/optimisation progressive du bytecode… ça devrait couvrir cette deuxième partie du spectre.
Je pense que les cas de unladden swallow (interpréteur python utilisant LLVM - http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html) ou encore de webkit (abandon de LLVM pour le JIT - https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/) sont assez clairs. Il est des cas que LLVM couvre excellemment, mais il ne faut absolument pas croire qu'il s'agit là du marteau universel. Ce marteau n'existe pas :)
Les langages dynamiques, l'absence d'optimisation progressive avec retour arrière… ce sont des défis que LLVM ne peut pas relever aujourd'hui. LLVM est conçu avec un modèle complètement statique, parfait pour de nombreux langages. Pour Java, à voir, mais je pense que des choses comme invokeddynamic risquent d'y perdre des plumes.
# Oracle... ton pire ennemi, ou presque !
Posté par Noobinux . Évalué à 10.
Depuis toujours, dès que je croise un projet qui utilise cette saloperie propriétaire qu’est JDK pour leur projet, je me permets de pousser le passage à OpenJDK. (pour diverses raisons évidentes)
J’en suis certainement à une bonne 15ène de projets à mon actif converti, et je suis ravi d’apprendre qu’à chaque fois, les développeurs tout comme les chefs de projet/produit, ne voient pas de soucis à ce que quelques “jours-homme” soient consacrés à ce passage à la liberté, sans licence, et avec bon nombres de points plus aisés (orchestration/automatisation/update/upgrade/etc.). Sans compter que sur le long terme, ne pas payer de licence signifie amortir ces “jours-homme” consommés.
D’ailleurs, on ne m’a jamais remonté quelque chose qui manquerait fonctionnellement parlant à propos d’OpenJDK par rapport à JDK (j’entends, des fonctionnalités vraiment vitales que les développeurs pourraient être amené à utiliser), et après analyse, les ressources consommés sont sensiblement les mêmes.
Pour finir, je suis bien content d’avoir poussé tous ces projets vers OpenJDK, ce n’est pas nouveau qu’Oracle souhaite récupérer des sous dans ces derniers outils encore utilisés et potentiellement rentable. (Néanmoins, ce n’est pas bien compliqué de comprendre les manœuvres du point de vue du financier à court terme, préparant son parachute… doré.)
[^] # Re: Oracle... ton pire ennemi, ou presque !
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Il faut quand même sacrément discipliner les développeurs qui n'en ont souvent rien à foutre de la qualité et de la durabilité (oh la belle classe dans com.sun.internal ! si je l'utilisais partout ?), mais oui l'openjdk c'est bon mangez en!
Oracle a perdu jenkins, bientôt Java… Vivement qu'ils relâchent complètement Netbeans et Virtualbox!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Oracle... ton pire ennemi, ou presque !
Posté par Glandos . Évalué à 3.
https://netbeans.apache.org/
Mais ça ne fait que Java pour l'instant (même pas J2EE).
[^] # Re: Oracle... ton pire ennemi, ou presque !
Posté par Nibel . Évalué à 6.
Il y a un seul cas où j'utilise JDK plutôt qu'OpenJDK : Minecraft.
Les performances sont largement supérieures (x2 voir x3 !) et certains mods ne fonctionnent pas avec OpenJDK (pas d'exemple en tête, ça doit bien faire un an que j'ai pas lancé le jeu…).
Mais sinon oui, j'essaye en général de d'utiliser OpenJDK quand il me suffit. Je n'ai pas un gros niveau en Java dans tous les cas, je n'utilise rien de particulier.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
# cloud
Posté par kna . Évalué à 2.
Euh, il y a le cloud oracle quand même : https://cloud.oracle.com/home (je ne l'ai jamais essayé cela dit).
[^] # Re: cloud
Posté par Psychofox (Mastodon) . Évalué à 7.
Ouais mais ils s'y sont pris tellement tard qu'ils sont à la bourre.
Accessoirement ils sont tellement aggressifs dans leur politique commerciale (en gros ils menacent de faire un audit toute boite qui ne migre pas vers le cloud) que leurs propres actionnaires les attaquent en justice.
[^] # Re: cloud
Posté par reynum (site web personnel) . Évalué à 10.
Quand je pense que Corneille le disait déjà : "Ô racle Ô désespoir" 😃
kentoc'h mervel eget bezan saotred
# Windows XP
Posté par xcomcmdr . Évalué à 8.
"Un peu comme Microsoft, qui s'en ait mis plein les poches avec la fin de la prise en charge (support) de Windows XP."
Euh, source ? Réécriture de l'histoire much ?
Windows XP a été pris en charge 13 ans. Un peu plus longtemps pour certains gouvernements qui traitent la sécurité comme la cinquième roue du carosse. Windows XP Embedded (la version embarqué, pour les distributeurs par exemple), est toujours pris en charge.
Un cas exceptionnel pour Microsoft, qui s'est vautré avec Longhorn/Vista, et a dû sortir le SP2 de XP en urgence face à Blaster et autres vers nommés ILoveYou et consorts.
À titre de comparaison, Windows 7 aura été pris en charge 11 ans.
Cette prise en charge étendue ne rapporte rien à MS (la vaste majorité des utilisateurs n'ont pas de contrat de support avec MS). Pour rappel, MS sortait jusqu'à Windows 10 un nouveau Windows environ tous les 3 ans. Entre XP et Vista il y a eu le double !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Windows XP
Posté par devnewton 🍺 (site web personnel) . Évalué à -1.
Ça évite des migrations vers d'autres OS.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Windows XP
Posté par xcomcmdr . Évalué à 3.
Source ?
Avant de migrer, faut des pilotes et application compatibles, au minimum. La mise à disposition de mises à jours de sécurité c'est ultra secondaire dans la décision de migrer si on a pas au moins ça…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Windows XP
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Essaie d'installer Windows XP sur un PC moderne qu'on rigole un peu. Normalement il va te demander d'insérer la disquette avec les drivers de ton contrôleur SATA.
[^] # Re: Windows XP
Posté par xcomcmdr . Évalué à 4.
Le rapport avec la choucroute ?
Windows XP est antédiluvien, oui. Microsoft s'en est rendu compte bien avant LinuxFR.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Windows XP
Posté par reynum (site web personnel) . Évalué à 10.
Hoax ! La communauté de Linuxfr savait que Windows était antédiluvien bien avant XP. 😸
kentoc'h mervel eget bezan saotred
[^] # Re: Windows XP
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
Antédiluvien, c'est bien cette adjectif qui qualifie une création tellement abjecte que Dieu a décidé de l'annihiler presque totalement ? Et Mirosoft qui était conscient de ce qu'est XP n'a pas agi plus tôt !!! et au contraire conservé deux fois plus longtemps. Mais c'est proprement satanique ça :-).
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Windows XP
Posté par Dring . Évalué à 7.
Pas vraiment, Antédiluvien ça veut juste dire que ça date d’avant le déluge.
[^] # Re: Windows XP
Posté par groumly . Évalué à 8.
C’est pas très flatteur pour les autres os si le seul truc qui retient les utilisateurs c’est l’absence de support sur un os vieux de 17 ans…
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Windows XP
Posté par xcomcmdr . Évalué à 4.
L'an prochain, XP sera assez vieux pour voter.
Et après les gens veulent que MS continuent de le prendre en charge. :D
Et la marmotte…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# GraalVM
Posté par barmic . Évalué à 5.
Du coup ils ont tellement eu peur d'Azul qu'ils ont créé GraalVM, c'est ça ?
Ça devait vraiment leur faire peur pour en arriver à publier ça sous licence GPLv2 :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.