Après six mois de développement, Oracle la plateforme (Java Platform, Standard Edition 15), le projet open source OpenJDK est utilisé comme implémentation de référence. Java SE 15 maintient une compatibilité ascendante avec les versions précédentes de la plate-forme Java ; tous les projets Java précédemment écrits fonctionneront sans modification une fois lancés sous la nouvelle version. Versions Java SE 15 prêtes à installer (JDK, JRE et Server JRE) pour Linux (x86_64), Windows et macOS. Implémentation de référence développée par le projet OpenJDK est entièrement open source sous licence GPLv2, avec des exceptions GNU ClassPath permettant une liaison dynamique avec des produits commerciaux.
Java SE 15 est classé comme version de support général et continuera à recevoir des mises à jour jusqu'à la prochaine version. La branche Long Term Support (LTS) devrait être Java SE 11, qui continuera à recevoir des mises à jour jusqu'en 2026. La précédente branche LTS de Java 8 sera prise en charge jusqu'en décembre 2020. La prochaine version LTS est prévue pour septembre 2021. Rappelons qu'à partir de la sortie de Java 10, le projet est passé à un nouveau processus de développement, impliquant un cycle plus court pour la formation des nouvelles versions. Les nouvelles fonctionnalités sont désormais développées dans une branche principale constamment mise à jour, qui comprend des modifications prêtes à l'emploi et à partir de laquelle des branches sont créées tous les six mois pour stabiliser les nouvelles versions.
De :
- prise en charge de l'algorithme de création de signature numérique EdDSA (Edwards-Curve Digital Signature Algorithm) ). L'implémentation EdDSA proposée ne dépend pas des plates-formes matérielles, est protégée contre les attaques par canal secondaire (un temps constant de tous les calculs est assuré) et est plus rapide en termes de performances que l'implémentation ECDSA existante écrite en langage C, avec le même niveau de protection. Par exemple, EdDSA utilisant une courbe elliptique avec une clé de 126 bits présente des performances similaires à ECDSA avec une courbe elliptique secp256r1 et une clé de 128 bits.
- prise en charge expérimentale des classes et interfaces scellées, qui ne peuvent pas être utilisées par d'autres classes et interfaces pour hériter, étendre ou remplacer l'implémentation. Les classes scellées fournissent également un moyen plus déclaratif de restreindre l'utilisation d'une superclasse que les modificateurs d'accès, basé sur une liste explicite des sous-classes autorisées pour l'extension.
package com.example.geometry ;
classe publique scellée
permet com.example.polar.Circle,
com.exemple.quad.Rectangle,
com.exemple.quad.simple.Square {…} - prise en charge des classes cachées qui ne peuvent pas être utilisées directement par le bytecode d'autres classes. L'objectif principal des classes cachées est d'être utilisées dans des frameworks qui génèrent dynamiquement des classes au moment de l'exécution et les utilisent indirectement, via . De telles classes ont généralement un cycle de vie limité, donc leur conservation pour l'accès à partir de classes générées statiquement n'est pas justifiée et ne fera qu'entraîner une augmentation de la consommation de mémoire. Les classes cachées éliminent également le besoin de l'API non standard sun.misc.Unsafe::defineAnonymousClass, dont la suppression est prévue à l'avenir.
- Le ramasse-miettes ZGC (Z Garbage Collector) a été stabilisé et est reconnu comme prêt à être utilisé à grande échelle. ZGC fonctionne en mode passif, minimise autant que possible la latence due au garbage collection (le temps de blocage lors de l'utilisation de ZGC ne dépasse pas 10 ms) et peut fonctionner avec des tas petits et énormes, dont la taille varie de plusieurs centaines de mégaoctets à plusieurs téraoctets.
- Stabilisé et trouvé prêt pour un usage général
Éboueur , travaillant avec des pauses minimales (Low-Pause-Time Garbage Collector). Shenandoah a été développé par Red Hat et se distingue par l'utilisation d'un algorithme qui réduit le temps de blocage lors du garbage collection en exécutant le nettoyage en parallèle avec l'exécution des applications Java. La taille des retards introduits par le garbage collector est prévisible et ne dépend pas de la taille du tas, c'est-à-dire pour les tas de 200 Mo et 200 Go les délais seront identiques ( au-delà de 50 ms et généralement dans les 10 ms) ; - Le support a été stabilisé et introduit dans la langue - une nouvelle forme de chaîne littérale qui vous permet d'inclure des données de texte multilignes dans le code source sans utiliser d'échappement de caractères et en préservant le formatage du texte d'origine dans le bloc. Le bloc est encadré par trois guillemets doubles.
Par exemple, au lieu de code
Chaîne html = " » +
"\n\t" + " » +
"\n\t\t" + " \"Java 1 est là !\" » +
"\n\t" + " » +
"\n" + " " ;vous pouvez préciser :
Chaîne html = """
» Java 1\
est là!
""" ; - Ancienne API DatagramSocket. Les anciennes implémentations de java.net.DatagramSocket et java.net.MulticastSocket ont été remplacées par une implémentation moderne plus facile à déboguer et à maintenir, et également compatible avec les flux virtuels développés au sein du projet. . En cas d'incompatibilité possible avec le code existant, l'ancienne implémentation n'a pas été supprimée et peut être activée à l'aide de l'option jdk.net.usePlainDatagramSocketImpl.
- Deuxième implémentation expérimentale proposée dans l'opérateur « instanceof », qui permet de définir immédiatement une variable locale pour accéder à la valeur vérifiée. Par exemple, vous pouvez immédiatement écrire « if (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..} » sans définir explicitement « String s = (String) obj ».
C'était:
if (obj instanceof Group) {
Groupe groupe = (Groupe) obj ;
var entrées = group.getEntries();
}Vous pouvez désormais vous passer de la définition « Group group = (Group) obj » :
if (obj instanceof Group group) {
var entrées = group.getEntries();
} - deuxième implémentation expérimentale du mot-clé "", qui fournit une forme compacte pour définir les classes, vous permettant d'éviter de définir explicitement diverses méthodes de bas niveau telles que equals(), hashCode() et toString() dans les cas où les données sont stockées uniquement dans des champs dont le comportement ne change pas. Lorsqu'une classe utilise des implémentations standards des méthodes equals(), hashCode() et toString(), elle peut se passer de leur définition explicite :
enregistrement public BankTransaction (date LocalDate,
double montant
Description de la chaîne) {}Cette déclaration ajoutera automatiquement les implémentations des méthodes equals(), hashCode() et toString() en plus des méthodes constructeur et getter.
- un deuxième aperçu de l'API Foreign-Memory Access, permettant aux applications Java d'accéder de manière sécurisée et efficace aux régions de mémoire en dehors du tas Java en manipulant les nouvelles abstractions MemorySegment, MemoryAddress et MemoryLayout.
- et a rendu obsolète la technique d'optimisation du verrouillage biaisé utilisée dans la JVM HotSpot pour réduire la surcharge de verrouillage. Cette technique a perdu de sa pertinence sur les systèmes dotés d'instructions atomiques fournies par les processeurs modernes et nécessite trop de main-d'œuvre à maintenir en raison de sa complexité.
- mécanisme obsolète , qui sera supprimé dans une prochaine version. Il est à noter que l'activation RMI est obsolète, reléguée à la catégorie des options dans Java 8 et n'est quasiment jamais utilisée dans la pratique moderne.
- Moteur JavaScript , qui était obsolète dans Java SE 11.
- ports pour le système d'exploitation Solaris et les processeurs SPARC (Solaris/SPARC, Solaris/x64 et Linux/SPARC). La suppression de ces ports permettra à la communauté d'accélérer le développement de nouvelles fonctionnalités OpenJDK sans perdre de temps à maintenir les fonctionnalités spécifiques à Solaris et SPARC.
Source: opennet.ru