For comparison, support for Linux/AArch64 platform was added in Java 9 and for Windows/AArch64 in Java 16. Nevertheless, the official stamp of approval is still important for the future maintenance and support for the platform. For people running on these platforms, this is not exactly news, as some vendors have already released versions of the JDK supporting this architecture, even backporting the support all the way back to Java 8.
This JEP improves the existing per-stream deserialization filters with a dynamic and context-sensitive filter selection mechanism.One of prominent JVM features added in this version is the support for macOS on AArch64 architecture with JEP 391, thus adding support for the new line of CPUs (M1) Apple released with their computers last year. JEP 415: Context-Specific Deserialization Filters This is the second iteration of Vector API introduced as JEP 338 in Java 16. It provides a way to work on memory out of Java runtime (thus out of garbage collection) and provides an alternative to JNI. This is the continuation of the work started with JEP 370 and JEP 383 for Foreign Memory access, and JEP 389 Foreign Linker API. JEP 412: Foreign Function & Memory API (Incubator) Probably not used at all, Security Manager will be deprecated. JEP 411: Deprecate the Security Manager for Removal The experimental AOT and JIT compilers using Graal compiler is going to be removed. JEP 410: Remove the Experimental AOT and JIT Compiler JEP 409: Sealed Classesįirst previewed in JDK 15, Sealed Classes are finalized with no changes from JDK 16. JEP 407: Remove RMI ActivationĪlready deprecated in JDK 15, RMI Activation mechanism will be removed. This is the first preview of Pattern Matching capability for switch. JEP 406: Pattern Matching for switch (Preview) Other than some critical internal APIs (such as ) where there is no alternative, other internal classes will be encapsulated in a way it will not be possible to easily make them available to programs. JEP 403: Strongly Encapsulate JDK Internals JEP 398: Deprecate the Applet API for RemovalĪpplet API is going to be removed so it is going to marked as deprecated.
Apple M1 processors) natively without using the Rosetta 2 translator. This JEP aims to port JDK to run on AArch64 platforms on macOS (e.g. This is going to be an internal change with no visible change on any APIs. This JEP will change Java 2D internal rendering pipeline from OpenGL to Apple Metal API.
This JEP will add six splittable (LXM family) and two other (Xoshiro256Plus and Xoroshiro128Plus) PRNG algorithm implementations. This JEP will introduce a new interface called RandomGenerator, and also four specialized sub-interfaces. It is difficult at the moment to have a custom PRNG implementation that can easily replace, because it is not an interface. This JEP will make it easy to use custom PRNG algorithms and provide a few concrete PRNG implementations. JEP 356: Enhanced Pseudo-Random Number Generators JEP 306: Restore Always-Strict Floating-Point SemanticsĪll floating-point operations by default will be like strictfp is used, so the results will be same on all platforms. The list is taken from the OpenJDK JDK 17 project page. 2: JDK 17 is in Rampdown Phase One, so the feature set is frozen.You need to use -enable-preview to use such features. If something is a preview feature, it is fully specified and implemented, but provided in a release to gather feedback, so it is not a permanent change yet. You need to use -add-modules to use incubator modules. API in such a module may change or completely removed (not released in any future JDK release). If something is implemented in an incubator module, it is not a permanent feature and it is released to get feedback from developers. I am planning to update this post when a new feature (JEP) is targeted for JDK 17, or when there is an important update on an already targeted JEP. This is an alive post of what will become Java 17, and, as expected, this post will expand and change over time, until the development of Java 17 is frozen in 2021.
0 kommentar(er)
