Bonjour, Habr! Je vous présente la traduction de l'article « 90 nouvelles fonctionnalités (et API) dans JDK 11 » de Simon Ritter.
Pour beaucoup, le nouveau cycle de publication JDK de six mois signifie que certains n'ont pas encore compris quelles sont les nouvelles fonctionnalités de JDK 10, et JDK 11 est sur le point. Dans l'un des premiers blogs , les 109 nouvelles fonctionnalités et API a pu être trouvé dans JDK 10. Par conséquent, pour JDK 11, il a été décidé de faire de même. Cependant, un format différent a été choisi. Ce message sera divisé en deux sections: les nouvelles fonctionnalités disponibles pour les développeurs (API publique) et tout le reste. Ainsi, si vous n'êtes intéressé que par ce qui affecte directement votre développement, vous pouvez ignorer la deuxième partie.
Le nombre total de modifications pouvant être calculées s'est avéré être de 90 (il s'agit de JEP plus de nouvelles classes et méthodes, à l'exclusion des méthodes distinctes pour le client HTTP et Flight Recorder ) ( note du traducteur: Java Flight Recorder (JFR) était l'un des modules complémentaires intégrés d'Oracle dans le JDK, mais à partir de Java 11, grâce au JEP 328 , il a été transféré en open source) . Bien que JDK 11 ait réussi à trouver onze changements de moins que dans JDK 10, je pense qu'il est juste de dire que davantage de fonctionnalités ont été ajoutées à JDK 11, certainement au niveau de la JVM.
Nouvelles fonctionnalités visibles par le développeur
JDK 11 a quelques changements qui pourraient affecter le style de développement. Il y a un léger changement de syntaxe, de nombreuses nouvelles API et la possibilité d'exécuter des applications dans un seul fichier sans utiliser de compilateur ( traducteur de notes: soi-disant fichiers shebang ). En outre, le changement majeur (et de rupture) est la suppression du module d'agrégation java.se.ee , qui peut affecter la migration d'une application existante vers JDK 11.
JEP 323: syntaxe de variable locale pour les paramètres Lambda
Dans JDK 10, l'inférence de variable locale (ou inférence de type) a été introduite ( JEP 286 ). Cela simplifie le code car vous n'avez plus besoin de spécifier explicitement le type de la variable locale, vous pouvez utiliser var à la place. JEP 323 étend l'utilisation de cette syntaxe, qui est désormais également applicable aux paramètres des expressions lambda. Un exemple simple:
list.stream() .map((var s) -> s.toLowerCase()) .collect(Collectors.toList());
Un programmeur Java attentif indiquerait que les expressions lambda ont déjà une inférence de type, donc utiliser var serait (dans ce cas) redondant. On pourrait tout aussi bien écrire le même code que:
list.stream() .map(s -> s.toLowerCase()) .collect(Collectors.toList());
Pourquoi ajouter le support var? La réponse est un cas particulier - lorsque vous souhaitez ajouter une annotation à un paramètre lambda. Cela ne peut se faire sans aucune implication. Pour éviter d'utiliser un type explicite, nous pouvons utiliser var pour simplifier les choses, de cette façon:
list.stream() .map((@Notnull var s) -> s.toLowerCase()) .collect(Collectors.toList());
Cette modification a nécessité des modifications de la spécification du langage Java (JLS) , en particulier:
Page 24: La description de l'identifiant spécial var.
Page 627-630: Paramètres Lambda
Page 636: évaluation à l'exécution des expressions Lambda
Page 746: syntaxe Lambda
JEP 330: lancement de programmes de code source à fichier unique
L'une des critiques de Java est la redondance de la syntaxe, et la «cérémonie» associée au lancement même d'une application triviale peut augmenter sérieusement le seuil d'entrée pour un débutant. Pour écrire une application qui affiche simplement «Bonjour tout le monde!», Vous devez écrire une classe avec la méthode principale public static void et utiliser la méthode System.out.println (). Cela fait, vous devez compiler le code à l'aide de javac. Enfin, vous pouvez lancer une application qui accueillera le monde. L'exécution du même script dans la plupart des langues modernes est beaucoup plus simple et plus rapide.
JEP 330 élimine le besoin de compiler une application à fichier unique. Entrez maintenant:
java HelloWorld.java
Le lanceur Java identifie que le fichier contient le code source Java et compile le code dans un fichier * .class avant de l'exécuter.
Les arguments placés après le nom du fichier source sont passés comme arguments au démarrage de l'application. Les arguments placés avant le nom du fichier source sont passés en tant qu'arguments au lanceur java après avoir compilé le code (cela vous permet de définir des choses comme classpath sur la ligne de commande). Les arguments liés au compilateur (par exemple classpath) seront également passés à javac pour la compilation.
Un exemple:
java -classpath /home/foo/java Hello.java Bonjour
Il sera équivalent à:
javac -classpath /home/foo/java Hello.java java -classpath /home/foo/java Hello Bonjour
Ce JEP prend également en charge les fichiers shebang. Pour réduire le besoin de mentionner même le lanceur Java sur la ligne de commande, vous pouvez l'inclure dans la première ligne du fichier source. Par exemple:
#!/usr/bin/java --source 11 public class HelloWorld { ...
L'indicateur -source avec la version de Java utilisée est requis.
JEP 321: client HTTP (standard)
JDK 9 a introduit une nouvelle API pour prendre en charge le protocole client HTTP ( JEP 110 ). Étant donné que JDK 9 fournissait le système de module de plate-forme Java (JPMS) , cette API a été incluse en tant que module d'incubateur . Les modules d'incubateur sont conçus pour fournir de nouvelles API, mais ne les transforment pas en standard Java SE. Les développeurs peuvent essayer l'API en fournissant des commentaires. Après avoir apporté les modifications nécessaires (cette API a été mise à jour dans JDK 10), l'API peut être transférée au module principal pour faire partie de la norme.
L'API du client HTTP fait désormais partie de la norme Java SE 11. Cela introduit un nouveau module et package pour le JDK, java.net.http . Classes principales:
- Httpclient
- Httprequest
- HttpResponse
- Prise Web
L'API peut être utilisée de manière synchrone ou asynchrone. En mode asynchrone, CompletionFutures et CompletionStages sont utilisés.
JEP 320: suppression des modules Java EE et CORBA
Avec l'introduction de JPMS dans JDK 9, il a été possible de diviser le fichier monolithique rt.jar en plusieurs modules. Un avantage supplémentaire de JPMS est que vous pouvez désormais créer un environnement d'exécution Java qui inclut uniquement les modules nécessaires à votre application, réduisant ainsi considérablement la taille globale. Avec des limites clairement définies, les modules obsolètes sont désormais plus faciles à supprimer de l'API Java. C'est ce que fait ce JEP; Le méta-module java.se.ee comprend six modules qui ne feront plus partie de la norme Java SE 11 et ne seront pas inclus dans le JDK.
Modules distants:
- corba ( note du traducteur:
repose en paix brûler en enfer ) - transaction
- activation
- xml.bind
- xml.ws
- xml.ws.annotation
Ces modules sont obsolètes (@Deprecated) depuis JDK 9 et n'étaient pas inclus par défaut dans la compilation ou le runtime. Si vous avez essayé de compiler ou d'exécuter une application à l'aide de l'API à partir de ces modules sur JDK 9 ou JDK 10, vous auriez échoué. Si vous utilisez l'API de ces modules dans votre code, vous devrez les fournir en tant que module ou bibliothèque distinct. À en juger par les critiques, il semble que les modules java.xml qui font partie de la prise en charge des services Web JAX-WS et SOAP soient ceux qui causeront le plus de problèmes.
Nouvelle API publique
La plupart des nouvelles API de JDK 11 sont le résultat du fait que le module client HTTP fait désormais partie de la norme, ainsi que l'inclusion de Flight Recorder.
Une liste schématique complète des modifications de l'API, y compris une comparaison des différentes versions du JDK, peut être trouvée ici.
Voici toutes les nouvelles méthodes autres que celles contenues dans les modules java.net.http et jdk.jfr. Les nouvelles méthodes et classes des modules java.security, qui sont assez spécifiques aux modifications JEP 324 et JEP 329, ne sont pas non plus répertoriées (il y a six nouvelles classes et huit nouvelles méthodes).
java.io.ByteArrayOutputStream
- void writeBytes (byte []) : écrit tous les octets de l'argument dans OutputStream
java.io.FileReader
Deux nouveaux constructeurs qui vous permettent de spécifier un jeu de caractères.
java.io.FileWriter
Quatre nouveaux constructeurs qui vous permettent de spécifier un jeu de caractères.
- io.InputStream nullInputStream () : renvoie un InputStream qui ne lit pas les octets. En regardant cette méthode (et celle de OutputStream, Reader et Writer), la question se pose de savoir pourquoi elle pourrait être utile. Vous pouvez les considérer comme / dev / null - pour supprimer la sortie dont vous n'avez pas besoin, ou fournir une entrée qui retourne toujours des octets nuls.
java.io.OutputStream
- io.OutputStream nullOutputStream ()
java.io.Reader
java.io.Writer
java.lang.Character
- String toString (int) : Il s'agit d'une forme surchargée d'une méthode existante, mais int est utilisé à la place de char. Int est le point de code Unicode.
java.lang.CharSequence
- int compare (CharSequence, CharSequence) : compare deux instances de CharSequence lexicographiquement . Renvoie une valeur négative, zéro ou une valeur positive si la première séquence est lexicographiquement inférieure, égale ou supérieure à la seconde, respectivement.
java.lang.ref.Reference
- lang.Object clone () : Je dois admettre que ce changement crée de la confusion. La classe Reference n'implémente pas l'interface Cloneable et cette méthode lève une exception CloneNotSupportedException. Il doit y avoir une raison pour son inclusion, peut-être pour quelque chose dans le futur. ( Note du traducteur: il y a une discussion sur StackOverflow , un ticket dans OpenJDK )
java.lang.Runtime
java.lang.System
Il n'y a pas de nouvelles méthodes ici, mais il convient de mentionner que la méthode runFinalizersOnExit () est désormais supprimée des deux classes (il peut y avoir un problème lors de la migration vers JDK 11).
java.lang.String
Je pense que c'est l'un des points forts des nouvelles API dans JDK 11. Il y a ici de nouvelles méthodes utiles.
- boolean isBlank () : retourne true si la chaîne est vide ou ne contient que des espaces, sinon false.
- Stream lines () : renvoie Stream from String, extrait de cette chaîne, séparé par des séparateurs de ligne.
- String repeat (int) : renvoie une chaîne dont la valeur est la concaténation de cette chaîne, répétée plusieurs fois.
- String strip () : renvoie une chaîne dont la valeur est cette chaîne, cela supprime tous les espaces au début et à la fin de la chaîne.
- String stripLeading () : renvoie une chaîne dont la valeur est cette chaîne, tout en supprimant tous les espaces au début de la ligne.
- String stripTrailing () : renvoie une chaîne dont la valeur est cette chaîne, cela supprime tous les espaces à la fin de la chaîne.
Très probablement, vous regardez strip () et demandez: "En quoi est-ce différent de la méthode trim () existante?" La réponse réside dans la différence de définition des espaces. ( note du traducteur: en bref, strip () comprend mieux Unicode, une analyse détaillée sur StackOverflow )
java.lang.StringBuffer
java.lang.StringBuilder
Ces deux classes ont une nouvelle méthode compareTo () qui prend un StringBuffer / StringBuilder et retourne un int. La méthode de comparaison lexicale est similaire à la nouvelle méthode compareTo () de CharSequence.
java.lang.Thread
Pas de nouvelles méthodes. Les méthodes destroy () et stop (Throwable) ont été supprimées. La méthode stop () , qui ne prend aucun argument, est toujours présente. Peut entraîner un problème de compatibilité.
java.nio.ByteBuffer
java.nio.CharBuffer
java.nio.DoubleBuffer
java.nio.FloatBuffer
java.nio.LongBuffer
java.nio.ShortBuffer
Toutes ces classes ont désormais la méthode mismatch () , qui recherche et renvoie l'index relatif de la première incompatibilité entre ce tampon et le tampon passé.
java.nio.channels.SelectionKey
- int interestOpsAnd (int) : définit atomiquement l'intérêt de cette clé (intérêt de la clé) à l'intersection au niveau du bit ("et") de l'ensemble d'intérêts existant et de la valeur transmise.
- int interestOpsOr (int) : définit atomiquement l'intérêt de cette clé (intérêt de la clé) dans l'union au niveau du bit ("ou") de l'ensemble d'intérêts existant et de la valeur transmise.
java.nio.channels.Selector
- int select (java.util.function.Consumer, long) : sélectionnez et effectuez des actions sur les touches dont les canaux correspondants sont prêts pour les opérations d'E / S. long argument est un délai d'attente.
- int select (java.util.function.Consumer) : comme ci-dessus, mais sans délai.
- int selectNow (java.util.function.Consumer) : comme ci-dessus, uniquement non bloquant.
java.nio.file.Files
- String readString (Path) : lit tout le contenu d'un fichier dans une chaîne, décodant d'octets en caractères à l'aide du codage UTF-8.
- String readString (Path, Charset) : comme indiqué ci-dessus, avec la différence que le décodage d'octets en caractères se produit en utilisant le jeu de caractères spécifié.
- Path writeString (Path, CharSequence, java.nio.file.OpenOption []) : écrire CharSequence dans un fichier. Les caractères sont codés en octets à l'aide du codage UTF-8.
- Path writeString (Path, CharSequence, java.nio.file.Charset, OpenOption []) : les mêmes que ci-dessus, les caractères sont codés en octets en utilisant le codage spécifié dans Charset.
java.nio.file.Path
- Path of (String, String []) : renvoie Path à partir de l'argument chaîne du chemin ou de la séquence de chaînes qui, une fois combinées, forment la chaîne de chemin.
- Chemin de (net.URI) : retourne le chemin depuis l'URI.
java.util.Collection
- Object [] toArray (java.util.function.IntFunction) : renvoie un tableau contenant tous les éléments de cette collection, en utilisant la fonction de génération fournie pour allouer le tableau renvoyé.
java.util.concurrent.PriorityBlockingQueue
java.util.PriorityQueue
- void forEach (java.util.function.Consumer) : exécute l'action transmise pour chaque élément Iterable jusqu'à ce que tous les éléments soient traités ou que l'action lève une exception.
- boolean removeAll (java.util.Collection) : supprime tous les éléments de cette collection qui sont également contenus dans la collection spécifiée (opération facultative).
- boolean removeIf (java.util.function.Predicate) : supprime tous les éléments de cette collection qui satisfont le prédicat donné.
- boolean retentionAll (java.util.Collection) : enregistre uniquement les éléments de cette collection qui sont contenus dans la collection transférée (opération facultative).
java.util.concurrent.TimeUnit
- conversion longue (java.time.Duration) : convertit la durée passée en ce type.
java.util.function.Predicate
- Predicate not (Predicate) : renvoie le prédicat, qui est la négation du prédicat transmis.
C'est l'une de mes nouvelles API préférées dans JDK 11. À titre d'exemple, vous pouvez convertir ce code:
lines.stream() .filter(s -> !s.isBlank())
dans
lines.stream() .filter(Predicate.not(String::isBlank))
ou si nous utilisons des importations statiques:
lines.stream() .filter(not(String::isBlank))
Personnellement, je pense que cette version est plus compréhensible et concise.
java.util.Optional
java.util.OptionalInt
java.util.OptionalDouble
java.util.OptionalLong
- boolean isEmpty () : Si aucune valeur, retourne true, sinon false.
java.util.regex.Pattern
- Prédicat asMatchPredicate () : Je pense que ce pourrait être le joyau de la nouvelle API JDK 11. Crée un prédicat qui vérifie si ce modèle correspond à la chaîne d'entrée donnée.
java.util.zip.Deflater
int deflate (ByteBuffer) : compresse l'entrée et remplit le tampon spécifié avec.
int deflate (ByteBuffer, int) : compresse l'entrée et remplit le tampon spécifié avec. Renvoie la quantité réelle de données compressées.
void setDictionary (ByteBuffer) : définit le dictionnaire spécifié pour la compression en octets dans ce tampon. Il s'agit d'une forme surchargée d'une méthode existante qu'un ByteBuffer peut désormais accepter, plutôt qu'un tableau d'octets.
void setInput (ByteBuffer) : définit l'entrée à compresser. Également une forme surchargée d'une méthode existante.
java.util.zip.Inflater
- int inflate (ByteBuffer) : décompresse les octets dans le tampon spécifié. Renvoie le nombre réel d'octets décompressés.
- void setDictionary (ByteBuffer) : définit le dictionnaire spécifié en octets dans ce tampon. La forme surchargée d'une méthode existante.
- void setInput (ByteBuffer) : définit l'entrée pour la décompression. La forme surchargée d'une méthode existante.
javax.print.attribute.standard.DialogOwner
Il s'agit d'une nouvelle classe dans JDK 11. Utilisée pour prendre en charge une demande de boîte de dialogue d'impression ou de mise en page. Doit être affiché au-dessus de toutes les fenêtres ou d'une fenêtre spécifique.
javax.swing.DefaultComboBoxModel
javax.swing.DefaultListModel
- void addAll (Collection) : ajoute tous les éléments présents dans la collection.
- void addAll (int, Collection) : ajoute tous les éléments présents dans la collection, à partir de l'index spécifié.
javax.swing.ListSelectionModel
- int [] getSelectedIndices () : renvoie un tableau de tous les indices sélectionnés dans le modèle sélectionné, dans l'ordre croissant.
- int getSelectedItemsCount () : renvoie le nombre d'éléments sélectionnés.
jdk.jshell.EvalException
- jshell.JShellException getCause () : retourne un wrapper de cause jetable dans le client d'exécution représenté par une EvalException, ou null si la cause n'existe pas ou est inconnue.
Nouvelles fonctionnalités (pas API publique)
JEP 181: Contrôle d'accès basé sur Nest
Java (et d'autres langages) prend en charge les classes imbriquées via les classes internes. Pour le bon fonctionnement, le compilateur doit effectuer quelques astuces. Par exemple:
public class Outer { private int outerInt; class Inner { public void printOuterInt() { System.out.println("Outer int = " + outerInt); } } }
Le compilateur modifie ceci pour créer quelque chose comme ceci avant de faire la compilation:
public class Outer { private int outerInt; public int access$000() { return outerInt; } }
class Inner$Outer { Outer outer; public void printOuterInt() { System.out.println("Outer int = " + outer.access$000()); } }
Bien que, logiquement, la classe interne fasse partie du même code que la classe externe, elle est compilée en tant que classe distincte. Par conséquent, cela nécessite une méthode synthétique ("bridge"), qui doit être créée par le compilateur pour fournir l'accès au champ privé de la classe externe.
Ce JEP représente le concept de «socket», où deux membres de la même socket (Outer et Inner de notre exemple) sont voisins. Deux nouveaux attributs ont été ajoutés au format de fichier * .class: NestHost et NestMembers. Ces modifications sont également utiles pour d'autres langages compilés par bytecode qui prennent en charge les classes imbriquées.
Cette fonctionnalité propose trois nouvelles méthodes pour java.lang.Class:
- Classe getNestHost ()
- Classe [] getNestMembers ()
- boolean isNestmateOf (clazz)
Cette fonctionnalité a également nécessité des modifications de la spécification de machine virtuelle Java (JVMS) , en particulier dans la section 5.4.4 Contrôle d'accès.
JEP 309: Constantes dynamiques de fichier de classe
Ce JEP décrit l'extension du format de fichier * .class pour prendre en charge le nouveau formulaire avec le pool constant CONSTANT_Dynamic (souvent appelé condy dans les présentations). L'idée d'une constante dynamique semble être un oxymore, mais, en fait, vous pouvez le considérer comme une valeur finale en Java. La valeur du pool de constantes n'est pas définie au stade de la compilation (contrairement aux autres constantes), mais la méthode d'amorçage est utilisée pour déterminer la valeur au moment de l'exécution. Par conséquent, la valeur est dynamique, mais comme sa valeur n'est définie qu'une seule fois, elle est également constante.
Cette fonctionnalité sera principalement utile à ceux qui développent de nouveaux langages et compilateurs. Qui générera les fichiers de bytecode et * .class pour les exécuter sur la JVM. Cela simplifiera certaines tâches.
Cette fonctionnalité fournit une nouvelle classe java.lang.invoke.ConstantBootstraps avec neuf nouvelles méthodes. Je ne les énumérerai pas tous ici; ce sont des méthodes d'amorçage pour les constantes calculées dynamiquement.
Cette fonctionnalité a nécessité des modifications du JVMS, en particulier, dans la façon dont le code d'octet d'invocation spécial et la section 4.4 de The Constant Pool sont utilisés.
JEP 315: Amélioration de l'intrinsèque Aarch64
Il s'agit du JEP fourni par Red Hat. La machine virtuelle Java peut désormais utiliser des instructions plus spécialisées disponibles dans le jeu de commandes Arm 64. Cela améliore en particulier le fonctionnement des méthodes sin (), cos () et log () de la classe java.lang.Math.
JEP 318: Le ramasse-miettes d'Epsilon
Red Hat a également contribué à ce JEP. Le ramasse-miettes Epsilon est quelque peu inhabituel car il ne ramasse pas les ordures! Il allouera de la nouvelle mémoire si nécessaire lors de la création de nouveaux objets, mais ne libère pas l'espace occupé par les objets sans liens.
Il semblerait, alors, quel est le point? Il y a au moins deux utilisations:
- Tout d'abord, ce collecteur est conçu pour garantir que les nouveaux algorithmes GC sont évalués en fonction de leur impact sur les performances. L'idée est d'exécuter un exemple d'application avec Epsilon GC et de générer une métrique. Un nouvel algorithme GC est inclus, les mêmes tests sont exécutés et les résultats sont comparés.
- Pour les tâches très courtes ou de courte durée (pensez à une fonction sans serveur dans le cloud), où vous pouvez vous assurer de ne pas dépasser la mémoire allouée à l'espace de tas. Cela peut améliorer les performances en éliminant la surcharge (y compris la collecte des statistiques nécessaires pour décider d'exécuter ou non le collecteur) dans le code d'application.
Si l'espace de mémoire est épuisé, l'opération JVM suivante peut être configurée de trois manières:
- Une OutOfMemoryError régulière est appelée.
- Réinitialiser le tas
- Arrêt dur de la JVM et éventuellement exécution d'une tâche externe (par exemple, démarrage du débogueur).
JEP 324: Accord clé avec Curve25519 et Curve448
Les normes cryptographiques sont en constante évolution et amélioration. Dans ce cas, le schéma Diffie-Hellman existant avec une courbe elliptique est remplacé par Curve25519 et Curve448. Il s'agit d'un schéma d'accord clé défini dans la RFC-7748.
JEP 327: Unicode 10
La plate-forme Java prend en charge Unicode pour permettre le traitement de tous les jeux de caractères. Depuis Unicode a été mis à jour vers la version 10 , le JDK a également été mis à jour pour prendre en charge cette version de la norme.
Je suis toujours intrigué de voir ce que les développeurs Unicode incluent dans les nouvelles versions. Unicode 10 compte 8 518 nouveaux caractères. Cela comprend le symbole Bitcoin, le jeu de caractères Nüshu (utilisé par les femmes chinoises pour écrire des poèmes) et Soyombo et la place Zanabazar (sont les caractères utilisés dans les textes bouddhistes historiques pour écrire le sanskrit, les langues tibétaine et mongole). De nombreux autres Emoji ont également été ajoutés, y compris le très attendu (apparemment) Colbert Emoji .
N'oubliez pas, à partir de JDK 9, vous pouvez utiliser UTF-8 dans les fichiers de propriétés (.properties). Cela signifie que tout caractère Unicode peut être utilisé dans de tels fichiers. Y compris les Emojis. Ou Nüshu.
JEP 328: Enregistreur de vol
Flight Recorder — JVM. JDK 11 Oracle JDK. , Oracle Oracle JDK OpenJDK, OpenJDK.
JEP :
: jdk.jfr jdk.management.jfr.
JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms
JEP 324, , JDK. ChaCha20 ChaCha20-Poly1305, RFC 7539. ChaCha20 — , , RC4.
JEP 331: Low-overhead Heap Profiling
, JEP, Google. Java JVM.
:
JEP 332: Transport Layer Security (TLS) 1.3
TLS 1.3 (RFC 8446) " " TLS . JDK , Datagram Transport Layer Security (DTLS).
JEP 333: ZGC A Scalable, Low Latency Garbage Collector
, , () . ( , Weak Generational Hypothesis ) ( ) GC . "" , . .
ZGC — region-based ( G1), NUMA aware compacting . .
pauseless , C4 Zing JVM.
JEP 335: Deprecate the Nashorn Scripting Engine
Nashorn JDK 8 Rhino Javascript . , Nashorn API jjs Java. , . Graal VM , , .
JEP 336: Deprecate the Pack200 Tools and APIs
Pack200 — JAR-, Java SE 5.0. JPMS JDK 9 Pack200 JDK. pack200 unpack200 API Pack200 java.util.jar JDK. , .
Conclusions
JDK 11 — LTS JDK ( ). , , , , JVM , .
Zulu JDK 11 !
JDK 11?
( . : , )