Now that Java 16 is features complete (Rampdown Phase Two at the day of writing), it\u2019s time to walk throught all the functionalities that brings to us, developers, this new version.<\/p>\n
This article is part of a series on what\u2019s new on the last versions of Java<\/a>, for those who wants to read the others, here are the links : Java 15<\/a>,, Java 14<\/a>, Java 13<\/a>, Java 12<\/a>, Java 11<\/a>,\u00a0Java 10,<\/a>\u00a0and\u00a0Java 9<\/a>.<\/p>\n This new version counts no less than 17 JEPs, but above all, sees the Records<\/strong> and the pattern matching for instanceof<\/strong> going out of preview and that’s good news!<\/p>\n First of all, a small description of what a Unix-Domain socket is:<\/p>\n The Example (non tested):<\/p>\n More info : JEP-380<\/a>.<\/p>\n Vector API is a new API which allows to express vector calculations (matrix calculation among others), which will be executed via optimal machine instructions depending on the execution platform.\nThese optimizations include changes within the Just In Time compiler, intrinsics, and use of AVX\/SSE instructions of CPUs which allow vectorization of calculations (SIMD type instructions – Single Instruction Multiple Data).<\/p>\n The JEP contains the following example, implemented before the Vector API by:<\/p>\n And with the Vector API by:<\/p>\n We use here a More info : JEP-338<\/a>.<\/p>\n With the JEP-393 Foreign-Memory API, which allows you to manage memory segments (on heap or off heap), this new functionality lays the foundations for the project Panama<\/a> by allowing the interconnection of the JVM with native code.<\/p>\n The Foreign Linker API makes it possible to call native code (in C for example) in an easy and performant way.<\/p>\n Here is an example of calling the More information on native function calls in this article by Maurizio Cimadamore: State of foreign function support<\/a>.<\/p>\n This code may seem a bit complex, that’s why jextract<\/strong> was created, which allows you to extract the code necessary to call a C library automatically from a C header file .<\/p>\n Example for calling the More information on jextract<\/strong> in this article, by Sundar Athijegannathan: Project Panama and jextract<\/a>.<\/p>\n OpenJDK 16 adds Alpine Linux support and thus Musl<\/a> as implementation of the C standard library for x64 and AArch64 architectures. More information in the JEP-386<\/a>.<\/p>\n OpenJDK 16 also adds support for the AArch64 architecture on Windows (previously only supported on Linux) via the JEP 388<\/a>. MacOS support on this architecture is in progress and will certainly be delivered in a future version of Java, see JEP 391<\/a>.<\/p>\n The following functionalities, which were in preview (or incubator module), are now standard.\nFor details about them you can refer to my previous articles.<\/p>\n The following functionalities remain in preview (or incubator module).\nFor details about them you can refer to my previous articles.<\/p>\n Various additions to the JDK :<\/p>\n During the modularization of the JDK via the Jigsaw project, some internal APIs of the JDK that should not be usable outside of it were nevertheless made usable (for lack of alternatives, or to give applications using them a migration time). This has been called Relaxed Strong Encapsulation<\/a>. A simple WARNING was displayed in the JVM logs the first time these APIs were used (behaviour that can be modified via A change in preparation for inline classes of project Valhalla: JEP 390<\/a> : Warnings for Value-Based Classes. Some JDK classes are called Value-Based Classes<\/strong>, these classes are only vehicles for data (data carier), and are therefore likely to be transformed into Inline Classes when the Valhalla project will be released. This is the case for example of the Optional class or wrappers on primitives.<\/p>\n Starting from Java 16, the use of these classes in a way incompatible with inline classes will generate warnings: use of constructors (which are deprecated), synchronization, incorrect use of the == or the !=.<\/p>\n Many intrinsics have been added to the JVM:<\/p>\n Java 16 has seen its share of JVM startup time optimizations. Claes Redestad, one of the Oracle engineers working on the subject, has written a rather interesting article which takes up the different optimizations of the JVM startup time since Java 8 and asks the question of the optimizations still to be done for Java 17: Towards OpenJDK 17<\/a>.<\/p>\n Release after release, the JVM startup time has been almost halved since Java 8 (after a significant increase in Java 9 following the introduction of modules). Knowing that a JVM starts in less than 40ms, Claes wonders if it is still necessary to work on this subject?<\/p>\n As for Java 16, we can note, among other things, many improvements in the CDS functionality:<\/p>\n CDS – Class Data Sharing, allows to save in an archive the classes metadata when the JVM is launched, in order to reuse them during successive launches, thus optimizing the JVM startup time.\nYou can find more information in my article QUARKUS, JLINK AND APPLICATION CLASS DATA SHARING (APPCDS)<\/a>.<\/p>\n The JVM contains a default archive with the metadata of certain classes from JDK, so changes to the CDS functionality automatically benefit to everyone.<\/p>","protected":false},"excerpt":{"rendered":" Now that Java 16 is features complete (Rampdown Phase Two at the day of writing), it\u2019s time to walk throught all the functionalities that brings to us, developers, this new version. This article is part of a series on what\u2019s new on the last versions of Java, for those who wants to read the others, here are the links : Java 15,, Java 14, Java 13, Java 12, Java 11,\u00a0Java 10,\u00a0and\u00a0Java 9. This new version counts no less than 17…JEP 380: Unix-Domain Socket Channels<\/h2>\n
Unix-Domain sockets are used for inter-process communication (IPC) on the same host. They are similar to TCP\/IP sockets in many ways, except that they are addressed by filesystem path rather than by IP addresses and port numbers.<\/blockquote>\n
SocketChannel<\/code> and ServerSocketChannel<\/code> classes can now be created from a Unix-Domain socket.<\/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> which allows to manage float vectors on 256 bits. The mul<\/code>, add<\/code>and neg <\/code> operations will therefore be done via SIMD instructions on 256 bits instead of being done individually on each float.<\/p>\nJEP 389: Foreign Linker API (Incubator)<\/h2>\n
strlen<\/code> function of the standard C library:<\/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> method of the C standard library:<\/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>\nTwo new ports of the JVM<\/h2>\n
Functionalities that go from preview to standard<\/h2>\n
Functionalities that stay in preview<\/h2>\n
Miscellaneous<\/h2>\n
T<\/code> into n elements R<\/code> via a 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>. These new methods are optimized through the addition of intrinsics.<\/li>\n<\/ul>\n--illegal-access<\/code>). With the JEP 396<\/a> : Strongly Encapsulate JDK Internals by Default, access to these APIs (which almost all have an official replacement in the JDK), is now forbidden by default. The default value of the flag --illegal-access<\/code> therefore changes from permit<\/code> to deny<\/code>. The flag is always present and can be modified to return to the previous behavior if necessary.<\/p>\nPerformance<\/h2>\n
Startup time<\/h2>\n