IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

JDK 17, l'implémentation de référence de Java 17, est en disponibilité générale.
La première version LTS depuis JDK 11 il y a trois ans s'accompagne de 14 JEP

Le , par Stéphane le calme

91PARTAGES

17  0 
Une nouvelle version de Java paraît tous les six mois, en mars et en septembre. Selon le cycle de vie du support d'Oracle Java SE, ceux-ci ne sont pris en charge que pendant six mois jusqu'à ce que la prochaine version apparaisse, tandis que les versions LTS sont prises en charge pendant huit ans.

Java 8 (la dernière avant une refonte majeure du JDK dans Java 9 avec de nombreuses modifications de rupture) a étendu la prise en charge jusqu'en décembre 2030, tandis que la prise en charge étendue de Java 11 s'étend jusqu'en septembre 2026.

Les fournisseurs d'éditions OpenJDK ouvertes de Java font en général des correspondance en terme de prise en charge. Il arrive qu'ils dépassent parfois ces dates de support, mais seules les éditions LTS sont destinées à une utilisation à long terme.

Quoi de neuf dans JDK 17 ?

Dans une liste de diffusion, il est expliqué que cette version comprend quatorze JEP (Java Enhancement Proposal):
  1. Restaurer une sémantique à virgule flottante toujours stricte (JEP 306)
  2. Générateurs de nombres pseudo-aléatoires améliorés (JEP 356)
  3. Nouveau pipeline de rendu macOS (JEP 382)
  4. portage du JDK sur macOS/Aarch64 (JEP 391)
  5. Dépréciation de l'API Applet pour suppression (JEP 398)
  6. Encapsuler fortement les composants internes du JDK (JEP 403)
  7. Pattern Matching pour switch (Preview, JEP 406)
  8. Suppression de l'activation RMI (JEP 407)
  9. Classes scellées (JEP 409)
  10. Suppression du compilateur expérimental AOT et JIT (JEP 410)
  11. Dépréciation du gestionnaire de sécurité pour la suppression (JEP 411)
  12. API de fonction étrangère et de mémoire (incubateur, JEP 412)
  13. API vectorielle (deuxième incubateur, JEP 414)
  14. Filtres de désérialisation spécifiques au contexte (JEP 415)

ainsi que des centaines d'améliorations plus petites et près de deux mille corrections de bugs.

Pour mémoire, un JEP est un document qui propose une amélioration de la technologie de base de Java. Ces propositions concernent généralement des améliorations qui ne sont pas encore prêtes à être spécifiées.

Les classes scellées (JEP 409)

Les classes scellées, qui ont été disponibles en préversion dans Java 15, restreignent les types qui peuvent en hériter. En Java, une classe scellée a une clause allows qui spécifie les sous-classes autorisées, comme dans*:

Code Java : Sélectionner tout
1
2
public abstract sealed class Shape
  permits Circle, Rectangle, Square { ... }

Suppression du compilateur AOT (ahead-of-time) et JIT (just-in-time) (JEP 410)

Selon l'équipe du JDK, le compilateur expérimental AOT et JIT a été très peu utilisé, mais nécessite un effort de maintenance important. Il est prévu de maintenir l'interface du compilateur de la JVM au niveau Java afin que les développeurs puissent continuer à utiliser des versions du compilateur construites en externe pour la compilation JIT. La compilation AOT (l'outil jaotc) a été intégrée au JDK 9 en tant que fonctionnalité expérimentale. Cet outil utilise le compilateur Graal, qui est lui-même écrit en Java, pour la compilation AOT.

Les mainteneurs avaient déjà annoncé plus tôt cette année que trois modules JDK seraient supprimés : jdk.aot (l'outil jaotc) ; internal.vm.compiler, le compilateur Graal ; et jdk.internal.vm.compiler.management, le MBean Graal. Le code HotSpot lié à la compilation AOT sera également supprimé.

Le compilateur HotSpot Just-in-time existe toujours et ceux qui souhaitent utiliser la compilation AOT ont été dirigés vers Graal.

Un nouveau pipeline de rendu macOS (JEP 382)

La JEP 382 prévoit d'ajouter au langage un nouveau pipeline de rendu pour macOS, utilisant l'API Apple Metal comme alternative au pipeline existant qui utilise l'API OpenGL dépréciée. Cette proposition vise à fournir un pipeline de rendu entièrement fonctionnel pour l'API Java 2D et qui utilise le framework Metal de macOS. Selon l'équipe du JDK, cela est nécessaire au cas où Apple supprimerait l'API OpenGL d'une future version de macOS. Le pipeline devrait avoir une parité fonctionnelle avec le pipeline OpenGL existant, avec des performances aussi bonnes ou meilleures dans certaines applications et certains benchmarks.

Une architecture propre serait créée et s'intégrerait dans le modèle Java 2D actuel. Le pipeline coexisterait avec le pipeline OpenGL jusqu'à son obsolescence. L'objectif de la proposition n'est pas d'ajouter de nouvelles API Java ou JDK.

Portage du JDK sur macOS/AArch64 (JEP 391)

La JEP 391 est un projet de portage du JDK sur macOS/AArch64 en réponse au projet d'Apple de faire passer ses ordinateurs Macintosh de x64 à AArch64. Un portage AArch64 de Java existe déjà pour Linux et des travaux sont en cours pour Windows. Les développeurs Java s'attendent à réutiliser le code AArch64 existant de ces ports en employant la compilation conditionnelle, comme c'est la norme dans les ports du JDK, pour tenir compte des différences dans les conventions de bas niveau telles que l'interface binaire de l'application et l'ensemble des registres réservés du processeur.

Les changements pour macOS/AArch64 risquent de casser les ports existants Linux/AArch64, Windows/AArch64, et macOS/x64, mais le risque devrait être réduit par des tests de préintégration.

Générateurs de nombres pseudo-aléatoires (JEP 356)

La JEP 356 prévoit des générateurs de nombres pseudo-aléatoires améliorés qui fourniraient de nouveaux types d'interfaces et d'implémentations pour les générateurs de nombres pseudo-aléatoires (PRNG – pseudorandom number generators), y compris les PRNG sautables et une classe supplémentaire d'algorithmes PRNG divisibles (LXM). Selon cette proposition, une nouvelle interface, RandomGenerator, fournira une API uniforme pour tous les PRNG existants et nouveaux. Quatre interfaces RandomGenerator spécialisées seront fournies.

Cette décision est motivée par l'accent mis sur de nombreux aspects à améliorer dans le domaine de la génération de nombres pseudo-aléatoires en Java. L'effort ne prévoit pas de fournir des implémentations de nombreux autres algorithmes PRNG. Mais trois algorithmes communs ont été ajoutés, qui sont déjà largement déployés dans d'autres environnements de langage de programmation. Les objectifs de cette stratégie sont les suivants :
  • faciliter l'utilisation de divers algorithmes PRNG de manière interchangeable dans les applications ;
  • améliorer la prise en charge de la programmation basée sur les flux, en fournissant des flux d'objets PRNG ;
  • éliminer la duplication de code dans les classes PRNG existantes ;
  • préserver le comportement existant de la classe java.util.Random.

Dépréciation de l'API Applet pour suppression (JEP 398)

Selon l'équipe du JDK, cette API est essentiellement sans intérêt, puisque tous les fournisseurs de navigateurs Web ont supprimé la prise en charge des plug-ins de navigateur Java ou ont annoncé leur intention de le faire. L'API Applet a déjà été dépréciée, mais pas pour être supprimée, dans Java 9 en septembre 2017.

Source : annonce de la disponibilité, note de version

Voir aussi

Oracle annonce la disponibilité de Java 16 : tour d'horizon des nouvelles fonctionnalités et améliorations du JDK
Java 15 est déjà sur les rails : la prochaine version standard ajoutera des blocs de texte et des Garbage Collectors, et supprimera le moteur JavaScript Nashorn
Java 14 est disponible en version définitive avec de nouvelles fonctionnalités de productivité des développeurs, dont Switch Expressions, Records et autres
Marquée obsolète depuis 2016, l'API Applet sera bientôt définitivement supprimée de Java. Y a-t-il des raisons de regretter les applets Java ?
Java : Oracle va marquer l'API Applet obsolète dans le JDK 9, mais n'a pas l'intention de la supprimer de sitôt

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de sunzoo
Membre du Club https://www.developpez.com
Le 01/10/2021 à 20:08
J'avais un prof qui mettait zéro s'il n'y avait pas de légende à un graphique
ici on nous balance des tests sans savoir ce qu'ils font (même la source ne le dit pas)
les tests B1 et le B10 sont intéressant car ils montrent une régression, malheureusement on reste sur sa faim ... zéro à Geoffrey
12  0 
Avatar de Pierre Louis Chevalier
Expert éminent sénior https://www.developpez.com
Le 16/09/2021 à 15:17
Citation Envoyé par darklinux Voir le message
Oracle aurait dû le faire il y a longtemps
Ce problème a été résolu avec l'open JDK, la Oracle ne fait qu'acter une correction sur sa politique stupide, pour essayer de tenter de sauver son image qui devient de plus en plus déplorable.

Citation Envoyé par darklinux Voir le message
Résultat Java n 'est plus crédible
Ça c'est faux, exemple : Emploi développeur 2020 : les langages les plus demandés et les mieux payés Java et JavaScript caracolent en tête


Citation Envoyé par darklinux Voir le message
et Oracle non plus
Ca c'est possible :
Oracle annonce les résultats financiers du Q1 de l'exercice 2022 : ses actions chutent en raison d'un manque à gagner, malgré un chiffre d'affaires IaaS et SaaS s'élevant à 2,5 milliards de $
Oracle accusé d'avoir « braconné » des employés clés de CentralSquare Technologies pour détourner des secrets commerciaux, afin de développer l'une de ses activités
Une suppression de plus d'un millier d'emplois par Oracle serait actuellement en cours dans ses filiales en Europe
7  0 
Avatar de damthemad
Membre actif https://www.developpez.com
Le 24/09/2021 à 9:28
ho la belle reculade.
Oracle a fait du mal à Java avec toutes ces décisions débiles et sa tentative pitoyable de racket.
Oracle est devenue une société voyou ; ils feraient mieux de créer des technologies que d'essayer d'étrangler leur clients.
2  0 
Avatar de smarties
Membre éprouvé https://www.developpez.com
Le 02/11/2021 à 8:33
C'est plus pratique OpenJDK, il est disponible dans les distributions Linux
Ensuite, vu ce qui s'est passé avec Google et Oracle (avec Android), il vaut mieux être prudent et ne plus utiliser les produits Oracle dis "gratuits"
2  0 
Avatar de SuperPat
Membre du Club https://www.developpez.com
Le 01/11/2021 à 13:27
"la licence donne le droit à l’utilisateur du JDK 17 d’en faire un usage interne à des fins de développement, de test, de prototypage et de démonstration de ses applications."

Donc finalement, rien de nouveau, on peut toujours pas utiliser l'Oracle JDK en production gratuitement ? Pour moi c'est toujours aussi confus, car le post du blog d'Oracle indique :

"Oracle is making the industry leading Oracle JDK available for free, including all quarterly security updates. This includes commercial and production use."
1  0 
Avatar de walfrat
Membre expérimenté https://www.developpez.com
Le 02/11/2021 à 9:50
En effet, la licence donne le droit à l’utilisateur du JDK 17 d’en faire un usage interne à des fins de développement, de test, de prototypage et de démonstration de ses applications. Ce droit avait déjà fait l'objet d'accord par Oracle pour les versions précédentes de son JDK dans le cadre de son contrat de licence OTN - Oracle Technology Network. En d'autres termes, l’utilisation du JDK 17 n’est pas permise sous la NFTC pour le développement des applications qu’un tiers ne développe pas ou ne possède pas en tant qu’entreprise.
En bref, soi tu vend ton application à l'entreprise qui donc la possède légalement et donc peux l'utiliser, quid de la maintenance assuré par le prestataire ?

Sinon si tu fourni un produit sous licence ce serait donc au fournisseur de l'application qui doit payer une licence Oracle puisque c'est lui qui possède l'application ?

"Oracle is making the industry leading Oracle JDK available for free, including all quarterly security updates. This includes commercial and production use."
Pire, ça fait de cette déclaration une déclaration mensongère.
1  0 
Avatar de Ithildine
Membre régulier https://www.developpez.com
Le 26/11/2021 à 12:28
Absence de visibilité à long terme... Chat échaudé...(vous connaissez la suite).

Si Oracle passait davantage de temps en R&D qu'en rédaction de licences obscures et ambigües pour, au final, ne jamais s'engager sur les points peu claires, savamment rédigés, et toujours laisser les gens sous le coup potentiel de licences à payer pour des sommes astronomiques, cela donnerait peut être, éventuellement, l'idée de considérer à nouveau d'utiliser leur JDK... et de mettre à la poubelle les heures de validations faites, contraints et forcés, pour continuer à livrer nos produits à nos clients...

En fait, non, je rigole, Oracle me paierait que je continuerai à fuir leurs produits et leurs licences comme la peste...
1  0 
Avatar de professeur shadoko
Membre chevronné https://www.developpez.com
Le 30/11/2021 à 11:49
Citation Envoyé par RenardSpatial Voir le message
Par contre, il manque visiblement un référentiel de traduction quelque part.
sujet épineux s'il en est!
Dans les années 80 on avait essayé de mettre au point des traductions de termes techniques anglais qui soient à la fois parlants et pas ridicules...
Il n'est certes pas interdit d'employer ces termes anglais directement (on mange bien des bifsteack!) mais parfois .... on avait ainsi par exemple le terme "cheminom" pour un "Path" d'accès au fichier... mais l'usage ne s'est pas imposé.
Dans mes cours Java (et dans mes bouquins) j'ai quand même utilisé quelques termes en Français avec parfois des décalques comme "accesseur" , "mutateur" (qui me semblent quand même un peu mieux que "getter" et "setter") mais il reste des points difficiles (par ex. pour "Thread" ou pour "Pattern")... sans tomber dans des excès on peut parfois trouver des termes qui sont à la fois parlants et agréables... mais comment faire pour que leur usage se répande?
Bon je sors car tout ceci relève d'un autre sujet à mettre dans un autre fil de discussion.
1  0 
Avatar de walfrat
Membre expérimenté https://www.developpez.com
Le 04/10/2021 à 12:49
Perso je vois une légende et aussi un caption pour chaque graphe.

Pour les tests qui ont été lancé, il s'agit sans doute de ceux là : https://github.com/kiegroup/optaplan...anner-examples
0  0 
Avatar de RenardSpatial
Membre régulier https://www.developpez.com
Le 29/11/2021 à 10:45
Je viens seulement de lire l’article suivant, qui me fait soulever deux réflexions :

Citation Envoyé par Bill Fassinou Voir le message
À quel point Java 17, la dernière version du langage, est-il plus rapide ?
La licence

Sauf erreur de ma part, l’article d’origine est sous licence Creative Commons 3.0, ce qui autorise la traduction qui a été faite ici mais pas sans préciser la licence de la source que je n’ai vue nulle part.

La cohérence de traduction

Dans cet article, le terme garbage collector a été rendu successivement par :

  • ramasse-miette
  • GC
  • éboueur
  • collecteur d’ordures
  • garbage collector (dans les liens en bas)


D’une part ça ne simplifie vraiment pas la compréhension ; d’autre part c’est la première fois que je vois les traductions « éboueur » ou « collecteur d’ordure ».

Je prends cet exemple parce qu’il est extrême, mais pour moi c’est un problème général à tout développez.com : je n’ai rien contre la traduction des termes utilisés (on pourrait se poser la question de la pertinence de la traduction du jargon sur un site à destination de personnes qui à priori le comprennent, mais ça n’est pas le sujet). Par contre, il manque visiblement un référentiel de traduction quelque part. Il reste aussi beaucoup de structures de phrases calquées sur l’anglais d’origine.
0  0