The class-file API, beforehand previewed in JDK 22 and JDK 23, could be finalized in JDK 24, with minor modifications. This API offers an ordinary API for parsing, producing, and remodeling Java class recordsdata. It goals to supply an API for processing class recordsdata that tracks the category file format outlined by the Java Digital Machine specification. A second aim is to allow JDK elements emigrate to the usual API, and finally take away the JDK’s inside copy of the third-party ASM library. Adjustments for the reason that second preview embrace a renaming of enum values, removing of some fields, the addition of strategies and technique overloads, strategies renamed, and removing of interfaces and strategies deemed pointless.
Late barrier enlargement for the G1 rubbish collector is meant to simplify the implementation of G1’s obstacles. The G1 rubbish collector’s obstacles document details about software reminiscence accesses, by shifting their enlargement from early within the C2 compilation pipeline to later. Objectives embrace lowering the execution time of C2 compilation when utilizing the G1 collector, making G1 obstacles understandable to HotSpot builders who lack a deep understanding of C2, and guaranteeing that C2 preserves invariants concerning the relative ordering of reminiscence accesses, safepoints, and obstacles. A fourth characteristic is preserving the standard of C2-generated JIT (just-in-time)-compiled code, by way of velocity and measurement.
The primary JDK 24-targeted characteristic, formally known as “Put together to Prohibit the Use of JNI,” requires issuing warnings about makes use of of JNI and adjusting the international perform and reminiscence (FFM) API, featured in JDK 22, to concern warnings in a constant method. These warnings are supposed to arrange for a future launch that ensures integrity by default by uniformly proscribing JNI and the FFM API. Objectives of the plan embrace preserving JNI as an ordinary solution to interoperate with native code, making ready the Java ecosystem for future releases that disallow interoperation with native code by default, and aligning the usage of JNI and the FFM API so library maintainers can migrate from one to the opposite with out requiring builders to alter command-line choices.
