Plus tôt cette année, Simon Ritter, directeur technique adjoint chez Azul Systems , a publié un article de blog couvrant les nouvelles fonctionnalités de Java 12 . Alors que Java 13 entrait dans le gel des fonctionnalités, InfoQ l’avait invité à parler de Java 12, 13 et de tout ce qui se passait chez Azul récemment.
InfoQ : Commençons par parler des produits Azul. Vous diffusez deux JDK distincts : Zulu, votre distribution OpenJDK, et Zing, une JVM propriétaire hautes performances. En quoi ces deux marchés diffèrent-ils pour vous en tant qu’entreprise ?
Simon Ritter : Zing est notre JVM commerciale, conçue pour optimiser les performances des applications Java nécessitant une faible latence et un débit élevé. Le marché concerné est celui d'utilisateurs dont la charge de travail ne peut être gérée par la nature non déterministe du ramasse-miettes.
Des applications telles que les systèmes de trading ou d'injection de publicités sur les pages Web ne peuvent tolérer des temps de pause du GC proportionnels à la taille du tas et nécessitent une approche différente. Zing est un ramasse-miettes réellement sans pause.
Zulu est notre distribution d'OpenJDK et s'adresse aux personnes qui souhaitent une alternative au JDK Oracle. Oracle a modifié la licence pour sa distribution à partir du JDK 11, ce qui signifie que de nombreuses personnes ayant utilisé les mises à jour gratuites doivent maintenant payer Oracle ou utiliser une distribution différente. Notre Zulu Enterprise Edition fournit une assistance complète avec un SLA sur les mises à jour disponibles à un coût très raisonnable. Cela plaît aux utilisateurs pour lesquels une version gratuite non prise en charge ne convient pas à leurs besoins.
InfoQ : Pour être tout à fait clair, les fichiers binaires Zulu que vous produisez sont-ils sous licence GPL et redistribuables librement ? Peuvent-ils être téléchargés à partir du site web Azul sans avoir à acheter une licence de support ?
Simon Ritter : Absolument. Nous avons deux versions de Zulu. Zulu Community Edition peut être téléchargé gratuitement sur notre site web et utilisé où vous le souhaitez. Zulu Enterprise Edition est la version commerciale avec support qui comporte des SLA pour la disponibilité des mises à jour et un canal de support pour la résolution des problèmes.
InfoQ : Vous avez également un produit pour les systèmes embarqués. Comment cela s’intègre-t-il à votre dans votre vision d'ensemble ?
Simon Ritter : Zulu Embedded est la troisième partie de notre gamme de produits destinée aux systèmes véritablement embarqués tels que les compteurs intelligents, les systèmes d’information multimédia pour voiture, etc... ou aux utilisateurs souhaitant regrouper un JDK avec leur code d’application pour simplifier l’installation.
InfoQ : Pouvez-vous nous parler de la feuille de route pour Zing (la JVM propriétaire d’Azul) ? Pendant de nombreuses années, le facteur de différenciation clé était le ramasse-miettes C4. Est-ce maintenant sous la menace de nouveaux ramasse-miettes dans OpenJDK, tels que ZGC et Shenandoah ? Comment répondez-vous à l'évolution du marché de la JVM ?
Simon Ritter : Essentiellement, nous recherchons en permanence de nouveaux moyens d’éliminer les problèmes de performance associés à la machine virtuelle Java. Le fait d'être un environnement d'exécution géré est excellent pour simplifier le développement et le déploiement, mais présente des inconvénients tels que les pauses du GC et le temps de warmup des applications lorsque les compilateurs JIT effectuent leur travail.
Nous avons commencé par résoudre le problème du GC en développant C4 (Continuously Concurrent Compacting Collector). Il y a eu quelques changements au fil des ans, mais l'approche fondamentale (utilisant LVB ou Load Value Barriere) reste la même.
Shenandoah adopte une approche différente de C4 et n’utilise actuellement qu’un seul tas générationnel. ZGC ressemble beaucoup plus à Zing dans son approche mais n’est pas complètement sans pause. Ces deux ramasse-miettes en sont encore au stade expérimental, donc je ne m'attends pas à ce que beaucoup de clients, en particulier ceux qui recherchent des SLA exigeants, les mettent en production dans un proche avenir. Nous regardons ce que font les autres avec intérêt.
InfoQ : Qu'en est-il des autres sous-systèmes de la JVM ?
Simon Ritter : Plus récemment, nous avons tourné notre attention vers d'autres parties de la JVM. Nous avons remplacé le C2 du JIT par notre JIT Falcon basé sur le compilateur LLVM. Cela donne d’excellents résultats en termes de performances, notamment dans des domaines tels que l’exploitation du traitement vectoriel. Pour réduire le temps de warmup, nous avons développé ReadyNow! qui prend un snapshot d'une application en cours d'exécution et l'utilise pour charger et initialiser des classes et compiler des méthodes avant que le point d'entrée principal ne soit exécuté.
Le développement le plus récent est Compile Stashing, qui enregistre le code compilé d’une application exécutée et l’utilise efficacement en tant que cache afin de réduire la quantité de compilation requise lorsque ReadyNow! est utilisé. Les spécifications de la JVM sont très détaillées sur ce que vous pouvez et ne pouvez pas faire au démarrage, ce qui rend difficile de passer le TCK (ce que nous faisons) lorsque nous apportons de nouvelles idées.
InfoQ : Certaines de ces technologies sont-elles open source? Est-il possible qu'ils soient ouverts à l'avenir ?
Simon Ritter : Comme il s’agit d’un produit commercial, nous ne mettons pas le code à disposition sous une licence open source. Que cela change dans le futur, il faudra attendre et voir !
InfoQ : Quelle est l'expérience de l'utilisation par Azul de l'utilisation de versions non-LTS de Java ? Est-ce que les gens les utilisent réellement dans leurs systèmes de production ?
Simon Ritter : Je suis speaker pour de nombreuses conférences et interroge toujours le public sur quelles versions du JDK ils utilisent en production. La plupart des gens sont toujours sous JDK 8 et un nombre croissant de personnes passent à 11. Le pourcentage de personnes qui ont migré vers JDK 11 varie toujours entre 10 et 15% lors des votes à main levée. Très peu de personnes utilisent les versions non-LTS sur la base de ces enquêtes informelles.
InfoQ : Parlons de Java 12 et en particulier de la nouvelle fonctionnalité Switch Expressions. À quel point pensez-vous que c'est utile ? D'après ce que vous avez vu, les développeurs l'adoptent-ils ?
Simon Ritter : Je pense que ceci est une fonctionnalité utile qui élimine un des points les plus difficiles en Java. Ayant une grande partie de sa syntaxe basée sur le C, Java a dû faire des choix tels qu'avec le switch où les choses auraient pu être faites différemment pour rendre la vie plus facile.
Devoir séparer les déclarations des cas individuels et le problème d'utiliser le fallthrough sans break ont toujours été quelque peu ennuyeux. Faire de switch une expression, ainsi qu’un traitement, est excellent car une assignation peut être faite en une seule fois, ce qui élimine une source potentielle d’erreurs.
Je n'ai entendu personne vanter cette fonctionnalité de la même manière que les Lambdas et les Streams. Comme il n’est disponible que dans JDK 12 (et seulement en mode preview), je suppose que son utilisation sera limitée jusqu’à la prochaine version LTS.
InfoQ : Qu'en est-il du mécanisme des fonctionnalités de Preview dans son ensemble ? Pensez-vous que cela s'avère utile ? Avez-vous des préoccupations à ce sujet ?
Simon Ritter : Je pense que ça marche bien. Le switch en tant qu'expression a été la première fonctionnalité ajoutée en tant que preview, et nous en avons déjà vu les avantages. La version 12 de JDK utilise 'break' avec une valeur pour conserver le look and feel de l'ancien style.
Bien que vous ne puissiez pas utiliser une valeur numérique en tant qu'étiquette, cela peut prêter à confusion si vous avez un code qui sort également d'une boucle avec une étiquette en conjonction avec une switch comme expression . Dans le JDK 13, la décision a été prise de changer cela pour plutôt utiliser 'yield' ( JEP 354 ) afin d'améliorer la clarté. S'il ne s'agissait pas d'une fonctionnalité en mode preview, il aurait été difficile de savoir si nous aurions pu effectuer le changement de cette manière, car la syntaxe aurait été incluse dans la spécification du langage Java SE.
InfoQ : Pouvez-vous comparer les fonctionnalités du langage en mode preview aux API en mode incubateur (telles que la prise en charge HTTP/2, initialement fournie en tant qu'incubateur) ? En quoi sont-ils différents les uns des autres, à votre avis ?
Simon Ritter : Ce sont vraiment les mêmes, sauf que l'un (modules incubateur) s'applique aux API et l'autre (fonctionnalités en mode preview) fait référence à la syntaxe du langage. Les deux permettent d'ajouter de nouvelles fonctionnalités sans modifier la spécification. Ils peuvent ensuite être modifiés, voire supprimés entièrement si les retours le justifie sans qu'il soit nécessaire de modifier les spécifications. Pour faire évoluer une plate-forme comme Java de manière réfléchie, ces approches ont beaucoup de sens.
Personnellement, j'aurais aimé que cela soit introduit il y a longtemps afin que nous puissions éviter certains problèmes.
InfoQ : Java 13 est sur le point de geler sa liste de fonctionnalités. Quelle est votre opinion sur le contenu de cette release - qui ne devrait pas changer de manière significative d’ici à la diffusion GA de Java 13 en septembre?
Simon Ritter : JDK 13 sera une autre version qui n'inclut pas un grand nombre de fonctionnalités. Il n'y a que cinq JEP qui doivent être incluses. Il est peu probable que les développeurs s’empressent de passer à cette version. L'idée de la nouvelle cadence de publication est un flux constant de nouvelles fonctionnalités nous donnant un rythme de changement similaire (voire même plus rapide) à celui auquel nous étions habitués avec l'ancien modèle de publication.
Actuellement, plusieurs gros projets sont en cours (Valhalla , Loom et Panama sont de bons exemples). Lorsque nous les verrons livrés, certaines versions comporteront de nombreuses nouvelles fonctionnalités. L'important est que Java continue d'évoluer et ne stagne pas.
InfoQ : S'agissant plus précisément des Text Blocks (auparavant appelés «chaînes multilignes»), s'agit-il d'un exemple d'application de la loi de Wadler ?
Simon Ritter : Oui, il est amusant de voir que certaines des plus petites fonctionnalités semblent nécessiter le plus de discussions. Java a eu plusieurs soucis avec la loi de futilité dans le passé.
Il y a de bons cas où les chaînes multi-lignes simplifieront la syntaxe mais ayant programmé en Java depuis JDK 1.0, je peux compter les fois où j'aurais vraiment eu besoin de cela sur les doigts d'une main.
InfoQ : Il y a eu des discussions animées sur les listes de diffusion OpenJDK récemment, auxquelles le personnel d'Azul (notamment Gil Tene) a participé - au sujet des images OpenJDK de Docker et comment le projet Debian prend les sources et construit des binaires pour ses versions. Pouvez-vous donner un aperçu de la question et décrire si vous estimez qu'elle a été résolue de façon satisfaisante ?
Simon Ritter : Le problème que Gil décrit comme "mystery meat JDKs" concerne l'utilisation abusive des chaînes de version pour les binaires JDK. Certains des binaires mis à disposition avaient des numéros de mise à jour pour la prochaine mise à jour avant qu'elle ne soit publiée.
Le problème est alors de savoir si quelque chose qui dit qu'il est JDK 8u212 contient réellement les modifications de cette mise à jour. Il existe de nombreuses sources de fichiers binaires JDK et les utilisateurs ont clairement besoin de savoir qu’ils obtiennent ce qu’ils pensent obtenir. Nous devrons voir comment cela fonctionnera dans les futures mises à jour avant de pouvoir être sûr que le problème ait été résolu.
InfoQ : OpenJDK 8 n'étant plus géré par Oracle, l'une des initiatives désormais possibles est le backport de fonctionnalités ou de correctifs qu'Oracle hésitait à entreprendre. L'un des exemples les plus visibles de cela est le backport de Java Flight Recorder (JFR) vers OpenJDK 8, dans lequel Azul a été particulièrement impliqué. Pouvez-vous expliquer pourquoi le backport est important, comment Azul s’y est impliqué et nous dire où nous en sommes avec le patch ?
Simon Ritter : Flight Recorder est un ensemble de fonctionnalités qui doivent être intégrées à la JVM pour permettre la collecte de métriques détaillées sur les performances de la JVM et d'une application. Ces données sont utilisées par l'application Mission control qu'Oracle a également rendu open source dans le cadre de la convergence entre le JDK Oracle et OpenJDK.
Le Flight Recorder d' Oracle est intégré au JDK 8. À ce moment-là, il s'agissait toujours d'une fonctionnalité commerciale qui nécessitait l'utilisation d'une licence payante pour une utilisation en production. Maintenant que les mises à jour publiques gratuites pour Oracle JDK 8 sont terminées (du moins pour les utilisateurs commerciaux), les utilisateurs migrent vers des versions OpenJDK 8 ne disposant pas de Flight Recorder.
Comme vous le dites, Azul a travaillé sur le backport de Flight Recorder vers OpenJDK 8 et l'inclut maintenant dans nos fichiers binaires Zulu 8. Nous travaillons avec d'autres contributeurs OpenJDK pour l'intégrer dans les sources OpenJDK .
InfoQ : Y a-t-il d'autres initiatives OpenJDK majeures dans lesquelles Azul est impliqué ou que vous aimeriez voir démarrer ?
Simon Ritter : Azul est fortement impliqué dans tous les aspects de l'écosystème Java. Nous faisons partie du comité exécutif du JCP depuis 2011 et du groupe d'experts Java SE depuis Java SE 9. L'un de nos ingénieurs, Andrew Brygin, est responsable du projet OpenJDK 6 et nous continuons à contribuer au projet OpenJDK avec des projets tels que la JEP 285 (Spin-Wait Hints). Nous continuerons de soutenir OpenJDK ainsi que la communauté Java dans son ensemble par le biais d'activités telles que les visites de JUG et le sponsoring d'AdoptOpenJDK.