Maintenant que Java 16 est features complete (Rampdown Phase Two au jour d\u2019\u00e9criture de l\u2019article), c\u2019est le moment de faire le tour des fonctionnalit\u00e9s qu\u2019apporte cette nouvelle version, \u00e0 nous, les d\u00e9veloppeurs.<\/p>\n
Cet article fait partie d\u2019une suite d\u2019article sur les nouveaut\u00e9s des derni\u00e8res versions de Java<\/a>, pour ceux qui voudraient les lire en voici les liens : Java 15<\/a>, Java 14<\/a>, Java 13<\/a>, Java 12<\/a>, Java 11<\/a>,\u00a0Java 10,<\/a>\u00a0et\u00a0Java 9<\/a>.<\/p>\n Cette nouvelle version compte pas moins de 17 JEP mais surtout voit les Records<\/strong> et le pattern matching pour instanceof<\/strong> sortir de preview et \u00e7a c’est une bonne nouvelle !<\/p>\n Tout d’abord une petite description de ce qu’est un socket de type Unix-Domain :<\/p>\n Les classes Exemple (non test\u00e9):<\/p>\n Plus d’info : JEP-380<\/a>.<\/p>\n Vector API est une nouvelle API qui permet d’exprimer des calculs de vecteur (calcul matriciel entre autres), qui seront ex\u00e9cut\u00e9s via des instructions machines optimales en fonction de la plateforme d’ex\u00e9cution.\nCes optimisations incluent des changements au sein du Just In Time compiler, des intrinsics, et utilisent les instructions AVX\/SSE des CPU qui permettent vectorisation des calculs (instructions de type SIMD – Single Instruction Multiple Data).<\/p>\n La JEP contient l’exemple suivant, impl\u00e9ment\u00e9 avant la Vector API par :<\/p>\n Et avec la Vector API par :<\/p>\n On utilise ici un Plus d’info : JEP-338<\/a>.<\/p>\n Avec la JEP-393 Foreign-Memory API, qui permet de g\u00e9rer des segments m\u00e9moire (on heap ou off heap), cette nouvelle fonctionnalit\u00e9 pose les bases du projet Panama<\/a> en permettant l\u2019interconnexion de la JVM avec du code natif.<\/p>\n La Foreign Linker API permet d’appeler du code natif (en C par exemple) de fa\u00e7on facile et performante.<\/p>\n Voici un exemple d’appel de la fonction Plus d’informations sur les appels de fonction native dans cet article de Maurizio Cimadamore : State of foreign function support<\/a>.<\/p>\n Ce code peut sembler un peu complexe, c’est pour cela qu’a \u00e9t\u00e9 cr\u00e9\u00e9 jextract<\/strong>, qui permet d’extraire le code n\u00e9cessaire \u00e0 l’appel d’une librairie C automatiquement depuis un fichier header C.<\/p>\n Exemple pour l’appel de la m\u00e9thode Plus d’informations sur jextract<\/strong> dans cet article, de Sundar Athijegannathan : Project Panama and jextract<\/a>.<\/p>\n OpenJDK 16 ajoute le support Alpine Linux et donc Musl<\/a> comme impl\u00e9mentation de la librairie standard C pour les architectures x64 et AArch64. Plus d’informations dans la JEP-386<\/a>.<\/p>\n OpenJDK 16 ajoute aussi le support de l’architecture AArch64 sous Windows (pr\u00e9c\u00e9demment uniquement support\u00e9 sous Linux) via la JEP 388<\/a>. Le support de macOS sur cette architecture est en cours et sera certainement livr\u00e9 dans une prochaine version de Java, voir la JEP 391<\/a>.<\/p>\n Les fonctionnalit\u00e9s suivantes, qui \u00e9taient en preview (ou en incubator module), sont maintenant en standard.\nPour les d\u00e9tails sur celles-ci vous pouvez vous r\u00e9f\u00e9rer \u00e0 mes articles pr\u00e9c\u00e9dents.<\/p>\n Les fonctionnalit\u00e9s suivantes restent en preview (ou en incubator module).\nPour les d\u00e9tails sur celles-ci vous pouvez vous r\u00e9f\u00e9rer \u00e0 mes articles pr\u00e9c\u00e9dents.<\/p>\n Divers ajouts au JDK :<\/p>\n Lors de la modularisation du JDK via le projet Jigsaw, certaines API internes du JDK qui ne devraient pas \u00eatre utilisables en dehors de celui-ci, ont quand m\u00eame \u00e9t\u00e9 rendues utilisables (par manque d’alternatives, ou pour donner aux applications les utilisant un temps de migration). C’est ce qui a \u00e9t\u00e9 appel\u00e9 Relaxed Strong Encapsulation<\/a>. Un simple WARNING \u00e9tait alors affich\u00e9 dans les logs de la JVM lors de la premi\u00e8re utilisation de ces API (comportement modifiable via Un changement en pr\u00e9paration des inline classes du projet Valhalla : JEP 390<\/a> : Warnings for Value-Based Classes. Certaines classes du JDK sont appel\u00e9es Value-Based Classes<\/strong>, ce sont des classes qui ne sont que des v\u00e9hicules pour de la donn\u00e9e (data carier), et sont donc susceptibles d’\u00eatre transform\u00e9es en Inline Classes quand le projet Valhalla sortira. C’est le cas par exemple de la classe \u00c0 partir de Java 16, l’utilisation de ces classes d’une mani\u00e8re incompatible avec les inline classes va g\u00e9n\u00e9rer des warnings : utilisation des constructeurs (qui sont d\u00e9pr\u00e9ci\u00e9s), synchronisation, utilisation incorrecte du == ou du !=.<\/p>\n Beaucoup d’intrinsics ont \u00e9t\u00e9 ajout\u00e9s \u00e0 la JVM :<\/p>\n Java 16 a vu son lot d’optimisations du temps de d\u00e9marrage de la JVM. Claes Redestad, l’un des ing\u00e9nieurs de chez Oracle qui travaille sur le sujet, a \u00e9crit un article assez int\u00e9ressant qui reprend les diff\u00e9rentes optimisations du temps de d\u00e9marrage de la JVM depuis Java 8 et se pose la question des optimisations encore \u00e0 faire pour Java 17 : Towards OpenJDK 17<\/a>.<\/p>\n Release apr\u00e8s release, le temps de d\u00e9marrage de la JVM \u00e0 quasiment \u00e9t\u00e9 divis\u00e9 par deux depuis Java 8 (apr\u00e8s un accroissement non n\u00e9gligeable en Java 9 suite \u00e0 l’introduction des modules). Sachant qu’une JVM d\u00e9marre en moins de 40ms, Claes se pose la question de savoir si c’est encore n\u00e9cessaire de travailler sur le sujet ?<\/p>\n Pour ce qui concerne Java 16, on peut noter, entre autre, de nombreuses am\u00e9liorations de la fonctionnalit\u00e9 CDS :<\/p>\n CDS – Class Data Sharing, permet d’enregistrer dans une archive les donn\u00e9es des metadatas des classes lors du lancement de la JVM, pour les r\u00e9utiliser lors de lancements successifs, optimisant alors le temps de d\u00e9marrage de cette derni\u00e8re.\nVous pourrez trouver plus d’informations dans mon article QUARKUS, JLINK ET APPLICATION CLASS DATA SHARING (APPCDS)<\/a>.<\/p>\n La JVM contient une archive par d\u00e9faut avec les metadatas de certaines classes du JDK, des changements sur la fonctionnalit\u00e9 CDS profitent donc automatiquement \u00e0 tout le monde.<\/p>","protected":false},"excerpt":{"rendered":" Maintenant que Java 16 est features complete (Rampdown Phase Two au jour d\u2019\u00e9criture de l\u2019article), c\u2019est le moment de faire le tour des fonctionnalit\u00e9s qu\u2019apporte cette nouvelle version, \u00e0 nous, les d\u00e9veloppeurs. Cet article fait partie d\u2019une suite d\u2019article sur les nouveaut\u00e9s des derni\u00e8res versions de Java, pour ceux qui voudraient les lire en voici les liens : Java 15, Java 14, Java 13, Java 12, Java 11,\u00a0Java 10,\u00a0et\u00a0Java 9. Cette nouvelle version compte pas moins de 17 JEP mais…JEP 380: Unix-Domain Socket Channels<\/h2>\n
Les sockets Unix-Domain sont utilis\u00e9s pour la communication inter-processus (IPC) sur le m\u00eame h\u00f4te. Ils sont similaires aux sockets TCP\/IP \u00e0 bien des \u00e9gards, sauf qu’ils sont adress\u00e9s par path de filesystem plut\u00f4t que par des adresses IP et des num\u00e9ros de port.<\/blockquote>\n
SocketChannel<\/code> et ServerSocketChannel<\/code> peuvent dor\u00e9navant \u00eatre cr\u00e9\u00e9es depuis un socket de type Unix-Domain.<\/p>\n\nServerSocketChannel serverSocketChannel = ServerSocketChannel.open();\nserverSocketChannel.socket().bind(UnixDomainSocketAddress.of(\"path\/to\/socket\/file\");\nwhile(true){\n SocketChannel socketChannel = serverSocketChannel.accept();\n \/\/do something with socketChannel...\n}\n<\/pre>\nJEP 338: Vector API (Incubator)<\/h2>\n
\nvoid scalarComputation(float[] a, float[] b, float[] c) {\n for (int i = 0; i <\/pre>\n\nstatic final VectorSpecies SPECIES = FloatVector.SPECIES_256;\n\nvoid vectorComputation(float[] a, float[] b, float[] c) {\n\n for (int i = 0; i <\/pre>\nFloatVector.SPECIES_256<\/code> qui permet de g\u00e9rer des vecteurs de float sur 256 bits. Les op\u00e9rations mul<\/code>, add<\/code> et neg<\/code> seront donc faites via des instructions SIMD sur 256 bits au lieu d’\u00eatre faites unitairement sur chaque float.<\/p>\nJEP 389: Foreign Linker API (Incubator)<\/h2>\n
strlen<\/code> de la librairie standard C :<\/p>\n\nMethodHandle strlen = CLinker.getInstance().downcallHandle(\n LibraryLookup.ofDefault().lookup(\"strlen\").get(),\n MethodType.methodType(long.class, MemoryAddress.class),\n FunctionDescriptor.of(C_LONG, C_POINTER)\n);\n\nlong len = strlen.invokeExact(CLinker.toCString(\"Hello\").address())\n<\/pre>\n
getpid<\/code> de la librairie standard C :<\/p>\n\necho \"int getpid();\" > getpid.h\njextract -t com.unix getpid.h\n<\/pre>\n
\nimport static com.unix.getpid_h.*;\n\nclass Main2 {\n public static void main(String[] args) {\n System.out.println(getpid());\n }\n}\n<\/pre>\nDeux nouveaux ports de la JVM<\/h2>\n
Les fonctionnalit\u00e9s qui passent de preview \u00e0 standard<\/h2>\n
Les fonctionnalit\u00e9s qui restent en preview<\/h2>\n
Divers<\/h2>\n
T<\/code> en n \u00e9l\u00e9ments R<\/code> via un Consumer<R><\/code><\/li>\n\nObjects.checkIndex(long index, long length)<\/code>, Objects.checkFromToIndex(long fromIndex, long toIndex, long length)<\/code>, Objects.checkFromIndexSize(long fromIndex, long size, long length)<\/code>. Ces nouvelles m\u00e9thodes sont optimis\u00e9es via l’ajout d’intrinsics.<\/li>\n<\/ul>\n--illegal-access<\/code>). Avec la JEP 396<\/a> : Strongly Encapsulate JDK Internals by Default, l’acc\u00e8s \u00e0 ces API (qui ont quasiment toutes un remplacement officiel dans le JDK), est maintenant interdit par d\u00e9faut. La valeur par d\u00e9faut du flag --illegal-access<\/code> passe donc de permit<\/code> \u00e0 deny<\/code>. Le flag \u00e9tant toujours pr\u00e9sent on peut le modifier pour retrouver le comportement pr\u00e9c\u00e9dent si n\u00e9cessaire.<\/p>\nOptional<\/code> ou des wrappers sur les primitives.<\/p>\nPerformance<\/h2>\n
Temps de d\u00e9marrage<\/h2>\n