- core-libs-dev - openjdk.org

RFD: A plan to untangle ZipFile.Source.initCEN
by Eirik Bjørsnøs 16 Feb '26

16 Feb '26

Hi, *Summary* Relieve ZipFile.Source.initCEN from non-parsing related responsibilities, such that it can become a pure function for parsing and validating CEN directories. Make it return Source, such that instance fields of this class may become final, immutable and accessible without synchronization. *Motivation* The method ZipFile.Source.initCEN has been the cause of a good amount of head-scratching over the years. It was brought over from the native implementation when this was transitioned to Java in Java 9. Risk assessments at that time probably constrained the code to closely align with the native code, which together with interpreter-friendliness in early startup have affected the current shape of this code. It is hard to summarize the responsibilities of this method, but I'll try: o Call findEND() to read metadata from the (Zip64) END headers in the ZIP file, validate fields and reject invalid values o Determine the position of the first LOC header o Read the CEN byte array from the ZIP file o Construct hash table data structures o Assign these to instance fields in Source o Parse and validate the CEN structure and populate hash table structures o Detect manifest file(s), signature related files and multi-release JAR versions o Detect when a ZIP has more CEN entries than declared by the END header and restart parsing by invoking itself recursively after counting the actual number of CEN entries o Detect when it is being invoked recursively to avoid reading the END and CEN headers twice It's been obvious for a while that this method performs an excessive number of unrelated tasks, knows too much about the state of the object being constructed and handles a disproportionate amount of funky control flow. It calls out to a number of helper methods to perform parsing and validation, some of them static, some relying on instance state. The amount of synchronization in ZipFile today is probably excessive for the current implementation. It made more sense back when ZipFile was backed by native code and resources. In particular, lookup misses pay a high relative cost to synchronization which is probably not needed. Making Source fields final moves us in a direction which may allow us to eventually remove synchronization for operations that only touch a parsed, immutable CEN. *Ideas and plan for improvements* I think we can improve the current situation by: o Moving END header parsing and validation out of initCEN o Moving CEN byte array reading out of initCEN o Making all helper methods static (it's a mix today) At this point, initCEN will almost, but not quite be a pure function for parsing the CEN byte array. So the next natural step is to actually make it a pure function by: o Making it static o Having it return a Source instance instead of assigning to the instance being constructed o Making Source (mostly) immutable by marking parsed instance fields as 'final' Rather than a big bang change, I see this effort as a step-by-step refactoring, probably over several PRs, each focusing on a smaller aspect of refactoring, hopefully making them easier to review. This is not an all-or-nothing effort, most of these changes will be incremental improvements on their own merit. If we don't get all the way, that's also okay. *Feedback?* Input to this idea/plan is welcome. If someone sees reasons this may not be a good idea, it's better to raise such concern here and now. Eirik.

2 5

RFR: 8377978: Add ZipFile test for skipping unrelated ENDSIG found in padded bytes
by Eirik Bjørsnøs 16 Feb '26

16 Feb '26

Please review this test-only PR which introduces a test for an edge case in `ZipFile.Source.findEND`. ZIP files may some times have bytes padded to them after the fixed-size END header. This may be bytes of the comment or just unrelated bytes. Because of this ,`ZipFile.Source.findEnd()` parses the ZIP file in a "backwards" manner, looking for ENDSIG sequences indicating that a candidate END header is found. If the position of the candidate END header and its declared comment length do not match up with the actual ZIP file length, this indicates padded bytes. In this case, `findEND()` will sanity check that the candidate END header points to LOCOFF and CENOFF positions which actually have the expected LOCSIG and CENSIG bytes. The case where a candidate END header is valid but has 'unexpected' bytes padded after it is currently tested by `ReadZip::bytesPaddedAtEnd`. However, there is no current testing for the case where an unrelated `ENDSIG` byte sequence is present in the padded bytes and the sanity check of the LOCOFF and CENOFF contents fails. This is edge case is propably rare in the real world, but it would still be nice to have an automated test of this scenario. ------------- Commit messages: - Update copyright year - Add test for skipping unrelated ENDSIG bytes while looking for the "real" END header Changes: https://git.openjdk.org/jdk/pull/29740/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29740&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377978 Stats: 33 lines in 1 file changed: 32 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29740/head:pull/29740 PR: https://git.openjdk.org/jdk/pull/29740

1 0

Add @Stable to Class#enumConstants.
by Ryan Hallock 16 Feb '26

16 Feb '26

Hello, I am new to OpenJDK development and I want to propose changes to Class#enumConstants from Class#getEnumConstants()/Class#getSharedEnumConstants(). Currently consider the following example: ```java enum E { A, B, C } E[] values = E.values(); E[] constants = E.class.getEnumConstants(); assert Arrays.equals(values, constants); ``` These methods provide an equal array of values, but they are treated differently. This is because the _constants_ stored by Class#enumConstants are non final and declared volatile. So C2 can't trust this call. Consider if I only wanted to access the value from an offset from these arrays. ```java E value = values[0]; E constant = constants[0]; assert value == constant; ``` _constant_ would never be folded but _value_ would be. So I propose the addition of @Stable annotation added to Class#enumConstants so _constant_ can be folded by C2. This is not a trivial change as it requires changing the data race to abide by @Stable. Could I be sponsored for this change (JBS issue as well)? A future proposal would be adding @Stable to Class#enumConstantDirectory, though that can be a seperate enhancement as that might require changing of the data structure to allow folding. Let me know if it should be combined as the Stable annotation itself would be implemented in a similar way for both. Thanks, Ryan Hallock

3 3

RFR: 8296183: jndiprovider.properties contains properties pointing to non-existing classes
by Jaikiran Pai 16 Feb '26

16 Feb '26

Can I please get a review of this change which removes the unused `src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties` file? This addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8296183. This `jndiprovider.properties` file lists 3 properties `java.naming.factory.control`, `java.naming.factory.object` and `java.naming.factory.state`. The semantics of these environment properties are explained in https://docs.oracle.com/javase/jndi/tutorial/beyond/env/provider.html. The classes configured in `com/sun/jndi/ldap/jndiprovider.properties` for each of these properties are non-existent in the JDK. Looking at the version control history of the JDK, these classes haven't been around for several releases (not even in JDK 8). The `jndiprovier.properties` gets looked up by an JDK internal class in the `java.naming` module - `com.sun.naming.internal.ResourceManager`. The `ResourceManager.getFactories(...)` method is the one that gets called to load the classes configured for those 3 environment properties. The javadoc of `ResourceManager.getFactories(...)` says this: Retrieves an enumeration of factory classes/object specified by a property. The property is gotten from the environment and the provider resource file associated with the given context and concatenated. ... The resulting property value is a list of class names. This method then loads each class using the current thread's context class loader and keeps them in a list. Any class that cannot be loaded is ignored. ... The implementation of `ResourceManager.getFactories(...)` matches that javadoc. Because the implementation ignores such missing classes, the reference to these non-existent classes in the `com/sun/jndi/ldap/jndiprovider.properties` has gone unnoticed all this while. Manual experiments of exercising this code path does indeed show that a `ClassNotFoundException` gets raised (and ignored) for the classes referenced in that `jnidprovider.properties` file. The commit in this PR removes the `jndiprovier.properties`. It also removes a javadoc reference to one of these non-existent classes. Given the nature of the change no new tests have been introduced and the existing tests in tier1, tier2 and tier3 continue to pass. ------------- Commit messages: - remove reference to a non-existent class from @see of EntryChangeResponseControl - 8296183: jndiprovider.properties contains properties pointing to non-existing classes Changes: https://git.openjdk.org/jdk/pull/29712/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29712&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296183 Stats: 21 lines in 3 files changed: 0 ins; 19 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29712.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29712/head:pull/29712 PR: https://git.openjdk.org/jdk/pull/29712

4 7

RFR: 8376665: Port fdlibm acosh to Java
by Anton Artemov 16 Feb '26

16 Feb '26

Hi, please consider the following changes: This is a port of FDLIBM acosh method. Original C vs transliteration port: $ diff -w fdlib_acosh.c.txt Acosh.translit.java 1c1,3 < /* __ieee754_acosh(x) --- > /** > * Return the Inverse Hyperbolic Cosine of x > * 7,8c9,10 < * acosh(x) := log(2x-1/(sqrt(x*x-1)+x)) if x>2; else < * acosh(x) := log1p(t+sqrt(2.0*t+t*t)); where t=x-1. --- > * := log(2x-1/(sqrt(x*x-1)+x)) if x>2; else > * := log1p(t+sqrt(2.0*t+t*t)); where t=x-1. 14,31c16,19 < < #include "fdlibm.h" < < #ifdef __STDC__ < static const double < #else < static double < #endif < one = 1.0, < ln2 = 6.93147180559945286227e-01; /* 0x3FE62E42, 0xFEFA39EF */ < < #ifdef __STDC__ < double __ieee754_acosh(double x) < #else < double __ieee754_acosh(x) < double x; < #endif < { --- > private static final class Acosh { > private static final double one = 1.0; > private static final double ln2 = 6.93147180559945286227e-01; > static double compute(double x) { 41c29 < return __ieee754_log(x)+ln2; /* acosh(huge)=log(2x) */ --- > return log(x)+ln2; /* acosh(huge)=log(2x) */ 46c34 < return __ieee754_log(2.0*x-one/(x+sqrt(t-one))); --- > return log(2.0*x-one/(x+sqrt(t-one))); 49a38 > } Transliteration vs more idiomatic port: $ diff -w Acosh.translit.java Acosh.fdlibm.java 5,7c5,9 < * Based on < * acosh(x) = log [ x + sqrt(x*x-1) ] < * we have --- > * > * > * acosh(x) is defined so that acosh(cosh(alpha)) = alpha, -INF < alpha < < INF > * and cosh(acosh(x)) = x, 1 <= x < INF. > * It can be written as acosh(x) = ln(x + sqrt(x^2 - 1)), 1 <= x < INF. 11a14,15 > * > * 16,17c20 < private static final class Acosh { < private static final double one = 1.0; --- > static final class Acosh { 18a22 > 23c27 < if(hx<0x3ff00000) { /* x < 1 */ --- > if(hx < 0x3ff00000) { // x < 1 */ 25,26c29,30 < } else if(hx >=0x41b00000) { /* x > 2**28 */ < if(hx >=0x7ff00000) { /* x is inf of NaN */ --- > } else if (hx >= 0x41b00000) { // x > 2**28 > if(hx >= 0x7ff00000) { // x is inf of NaN 28,29c32,34 < } else < return log(x)+ln2; /* acosh(huge)=log(2x) */ --- > } else { > return Log.compute(x) + ln2; // acosh(huge) = log(2x) > } 31,32c36,37 < return 0.0; /* acosh(1) = 0 */ < } else if (hx > 0x40000000) { /* 2**28 > x > 2 */ --- > return 0.0; // acosh(1) = 0 > } else if (hx > 0x40000000) { // 2**28 > x > 2 34,37c39,42 < return log(2.0*x-one/(x+sqrt(t-one))); < } else { /* 1<x<2 */ < t = x-one; < return log1p(t+sqrt(2.0*t+t*t)); --- > return Log.compute(2.0 * x - 1.0 / (x + Sqrt.compute(t - 1.0))); > } else { // 1< x <2 > t = x - 1.0; > return Log1p.compute(t + Sqrt.compute(2.0 * t + t * t)); ------------- Commit messages: - 8376665: Fixed whitespaces. - 8376665: Fixed whitespaces. - 8376665: Ported fdlibm acosh function. Added tests. - Merge remote-tracking branch 'origin/master' into JDK-8375285-port-fdlibm-asinh-to-java - 8375285: Added versions. - 8375285: Addressed the reviewer's comments, fixed year in the copyright notice. - 8375285: Addressed the reviewer's comments. - 8375285: Port of fdlibm asinh function Changes: https://git.openjdk.org/jdk/pull/29488/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29488&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376665 Stats: 1163 lines in 7 files changed: 1149 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/29488.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29488/head:pull/29488 PR: https://git.openjdk.org/jdk/pull/29488

4 17

RFR: 8377944: LowMemoryTest2.java#id1 intermittent fails OOME: Metaspace
by SendaoYan 15 Feb '26

15 Feb '26

Hi all, Test java/lang/management/MemoryMXBean/LowMemoryTest2.java#id1 intermittent fails "java.lang.OutOfMemoryError: Metaspace". The test log shows that MemoryPoolMXBean.isUsageThresholdExceeded() always return true but MemoryPoolMXBean.getUsageThresholdCount() always return zero. The comment in this test says that "UsageThresholdCount is only updated during GC.", so it seems that the System.gc() do not trigger GC actually, so test always allocate new classes and then throw OOME in metaspace. This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `System.gc()` to make sure the GC to be trigger all the time. Change has been verified locally on linux-aarch64 and linux-x64. ------------- Commit messages: - Update copyright year - 8377944: LowMemoryTest2.java#id1 intermittent fails OOME: Metaspace Changes: https://git.openjdk.org/jdk/pull/29729/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29729&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377944 Stats: 16 lines in 1 file changed: 2 ins; 4 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/29729.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29729/head:pull/29729 PR: https://git.openjdk.org/jdk/pull/29729

1 0

RFR: 8373288: EnumMap spliterators should include more specific characteristics
by Patrick Strawderman 14 Feb '26

14 Feb '26

The spliterators returned by keySet, entrySet, and values were not reporting additional characteristics, such as ORDERED, SORTED, and NONNULL; the EnumMap iterators all guarantee iteration is in the natural order of the enum key, and nulls are disallowed as keys. Null values are allowed, so the values collection can only additionally report ORDERED. ------------- Commit messages: - Update copyright year - 8373288: EnumMap spliterators should include more specific characteristics Changes: https://git.openjdk.org/jdk/pull/28840/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28840&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373288 Stats: 140 lines in 2 files changed: 138 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28840.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28840/head:pull/28840 PR: https://git.openjdk.org/jdk/pull/28840

4 3

RFR: 8377857: Add since checker test for java.naming module
by Jaikiran Pai 14 Feb '26

14 Feb '26

Can I please get a review of this change which introduces a test to verify the usages of `@since` javadoc tags in the `java.naming` module? This addresses https://bugs.openjdk.org/browse/JDK-8377857. The `SinceChecker` test utility has been in use for several modules, but wasn't added for java.naming. The commit in this PR adds one for that module. The `SinceChecker` test utility does not handle the presence of a comma in (for example `@since X, Y`) correctly. The javadoc tag spec for `@since` allows that syntax https://docs.oracle.com/en/java/javase/25/docs/specs/javadoc/doc-comment-sp…. As a workaround, the commit in this PR splits the `@since` on `javax.naming.InitialContext` class into two separate declarations (this too is allowed by the `@since` tag spec). I've verified that the generated javadoc continues to correctly show these values. I have also spoken to Nizar about this issue in SinceChecker and it will be addressed separately. ------------- Commit messages: - 8377857: Add since checker test for java.naming module Changes: https://git.openjdk.org/jdk/pull/29705/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29705&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377857 Stats: 32 lines in 2 files changed: 30 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29705.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29705/head:pull/29705 PR: https://git.openjdk.org/jdk/pull/29705

2 9

Re: RFR: 8377712: ConstantPool of WeakReferenceKey is not deterministic in CDS archive
by Ioi Lam 14 Feb '26

14 Feb '26

On Thu, 12 Feb 2026 05:58:15 GMT, Chen Liang <liach(a)openjdk.org> wrote: > Or a better fix would be removing the == path for all reference keys. There's no case where this hits because you are always creating a new strong key. Missing use of class constant means the equals method is completely unused. As we discussed offline, I updated `ensureDeterministicAOTCache()` to call `WeakReferenceKey::equals()` instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29678#issuecomment-3901302276

1 0

[jdk26] RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests
by SendaoYan 14 Feb '26

14 Feb '26

Hi all, This pull request contains a backport of commit [34f24131](https://github.com/openjdk/jdk/commit/34f241317ecd7473cfb6dcc2e6e… from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by SendaoYan on 15 Dec 2025 and was reviewed by Leonid Mesnik and David Holmes. Thanks! ------------- Commit messages: - Backport 34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c Changes: https://git.openjdk.org/jdk/pull/28826/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28826&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371503 Stats: 32 lines in 11 files changed: 2 ins; 20 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/28826.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28826/head:pull/28826 PR: https://git.openjdk.org/jdk/pull/28826

3 8