La réponse de Stephen C est correcte et importante.

Oracle n'a plus l'intention pour les utilisateurs finaux d'installer un JRE ou un JDK. Applets Javadans un navigateur et Java Web Start app delivery sont tous deux en cours de suppression, laissant l'utilisateur final sans besoin d'un JRE. Les applications basées sur Java devraient regrouper leur propre implémentation Java. Les seules personnes qui installeront consciemment un JDK seront les développeurs et le côté serveur sysadmin.

Important:

• Comprendre clairement la nature du projet OpenJDK , comme expliqué dans Wikipedia
• Lire ce livre blanc par Oracle de 2018-03, Mise à jour de la feuille de route du client Java
• Lire le livre blanc Java Est Encore Libre, rédigé par des membres clés de la communauté Java.

En savoir plus sur:

• Module de Plateforme Java Système
• jlink (PEC 282)
• jpackage (PEC 343)

Les applications de bureau devraient désormais regrouper leur propre runtime Java. Les outils énumérés ci-dessus peuvent créer un très petit runtime personnalisé pour votre application particulière.

Voici un diagramme de flux qui peut vous aider à trouver et à décider parmi les différents fournisseurs fournissant une implémentation Java 11.

Et un tableau cartographie des motivations ou considérations possibles menant à des fournisseurs suggérés de Java.

Problèmes de compatibilité

Dans les commentaires, une question a été soulevée, préoccupation sur les problèmes de compatibilité entre les versions par divers fournisseurs.

Tout d'abord, sachez que le projet OpenJDK comprend une vaste suite de tests connue sous le nom deOpenJDK Community Technology Compatibility Kit (TCK) . Les fournisseurs sont libres de déclarer eux-mêmes si leur libération est passée ces tests. Ces affirmations ne sont pas vérifiées et reposent sur le système d'honneur. Sur mon diagramme ci-dessus, j'ai coché "TCK" sur les deux fournisseurs que je connais qui se sont auto-déclarés: Oracle JDK by Oracle & Zulu by Azul Systems.

Tous les produits répertoriés dans la zone blue barrel de mon graphique ci-dessus sont construits presque directement sur le code source OpenJDK. Donc, généralement, vous devriez voir une compatibilité pratiquement identique.

Il y a deux domaines de préoccupation que vous pourriez considérer: les différences technologiques, et calendrier des mises à jour/correctifs.

En ce qui concerne les différences technologiques, les fournisseurs utilisant le projet OpenJDK peuvent expédier avec le HotSpot engineou le OpenJ9 engine. Ceux-ci différeront sur les performances (démarrage plus rapide/plus lent par rapport à la vitesse globale, plus/moins de mémoire), mais leur comportement en termes de conformité aux spécifications Java devrait être identique. Ils pourraient différer, et certainement l'un ou l'autre pourrait présenter un défaut (qui serait probablement bientôt corrigé) que l'autre manquer. Personnellement, je ne serais pas concerné par cela, mais je le mentionne pour être complet.

Une autre différence technologique est le type différent de JVM utilisé par Zing par Azul Systems et GraalVM par Oracle. L'un ou l'autre de ces peut différer d'une manière ou d'une autre des autres produits, car ils ont intentionnellement un type d'implémentation JVM différent, pour offrir des fonctionnalités spéciales. Mais étant donné la rigueur desspécifications Java , elles ne devraient pas être incompatibles. Si ils étaient, vous pouvez vous attendre à ce que tout problème de compatibilité soit rapidement résolu. Si j'avais besoin des caractéristiques spéciales de l'un ou l'autre de ces produits, je les utiliserais en toute confiance.

Une autre préoccupation possible est la rapidité avec laquelle un fournisseur peut mettre à jour ses propres versions avec certaines corrections de bugs ou correctifs de sécurité. Par exemple, Oracle a déclaré qu'il se réservait le droit d'expédier immédiatement tous les correctifs prêts à leurs propres clients, tout en les soumettant au projet OpenJDK pour considération. Certes, l'un des fournisseurs fournissant un support commercial est susceptible de précipiter un correctif ou un correctif à leurs clients payants. Ces versions construites par courtoisie à la communauté fournies gratuitement peuvent prendre plus de temps à mettre à jour, probablement après que le projet OpenJDK a incorporé un correctif/correctif.

Et chaque fournisseur est libre de modifier sa base de code à volonté, tant qu'ils sont conformes aux spécifications Java. Par exemple, l'équipe Corretto d'Amazon a déjà apporté des améliorations à leur propre version, puis partagé ces changements en amont du projet OpenJDK. Il peut y avoir un écart de temps avant qu'OpenJDK incorpore ces changements, s'ils décident de le faire. Il est donc possible que différentes versions diffèrent. Mais à ce stade, tous les fournisseurs de la communauté Java semblent avoir des engagements sincères à travailler ensemble pour éviter la fragmentation. Donc, encore une fois, je n'ai aucune préoccupation réelle ici, mais mentionnez ceci pour être complet.

Vous pouvez utiliser le site Web du projet" adoptopenjdk " pour télécharger les derniers jre et JDK https://github.com/AdoptOpenJDK/openjdk-jdk11

Trouver le dernier lien ici > https://adoptopenjdk.net/releases.html?variant=openjdk11&jvmVariant=hotspot

Modifier: Le problème a été résolu

J'ai utilisé leurs versions de nuit pour contourner le problème de JRE manquant dans le package JDK https://adoptopenjdk.net/nightly.html?variant=openjdk11