Re: RFR: 8368226: Remove Thread.stop [v3]

2025-09-24 Thread Alan Bateman
> JDK-8360979 is fixed then no change to KDC is needed. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the

Re: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v2]

2025-09-23 Thread Alan Bateman
On Tue, 23 Sep 2025 14:39:34 GMT, Vladimir Ivanov wrote: >> src/hotspot/share/runtime/fieldDescriptor.cpp line 53: >> >>> 51: // write protected fields (JLS 17.5.4) >>> 52: if (is_final() && is_static() && ik == vmClasses::System_klass() && >>> 53: (offset() == java_lang_System::in_off

Re: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v2]

2025-09-23 Thread Alan Bateman
means that jtreg will launch the agent with the command > line options to open the package. > > Testing: tier1-6 Alan Bateman has updated the pull request incrementally with two additional commits since the last revision: - Review feedback - Change ciField::initialize_from to use is_

Re: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final

2025-09-23 Thread Alan Bateman
On Mon, 15 Sep 2025 13:53:28 GMT, Chen Liang wrote: >> Implementation changes for [JEP 500: Prepare to Make Final Mean >> Final](https://openjdk.org/jeps/500). >> >> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny >> when mutating a final instance field. JFR event r

Re: Add Multipath TCP (MPTCP) Support to the Java Networking API

2025-09-23 Thread Alan Bateman
On 23/09/2025 10:55, Geliang Tang wrote: Following your suggestion, I have started a new thread on net-dev: Add Extended MPTCP (Multipath TCP) Socket Option Support to OpenJDK https://mail.openjdk.org/pipermail/net-dev/2025-September/028085.html Thanks, let's continue the discussion there. -

Re: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort)

2025-09-22 Thread Alan Bateman
On Mon, 22 Sep 2025 20:40:47 GMT, Vladimir Yaroslavskiy wrote: > Do you agree, if I move Radix sort out from this PR and re-run benchmarking? > And later, after integration of these optimizations, we will return to > discussion of Radix sort, what do you think? Yes, splitting this into two wo

Re: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final

2025-09-22 Thread Alan Bateman
On Mon, 22 Sep 2025 17:08:20 GMT, Chen Liang wrote: >> Implementation changes for [JEP 500: Prepare to Make Final Mean >> Final](https://openjdk.org/jeps/500). >> >> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny >> when mutating a final instance field. JFR event r

Re: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final

2025-09-22 Thread Alan Bateman
On Mon, 15 Sep 2025 18:18:02 GMT, Chen Liang wrote: >> Implementation changes for [JEP 500: Prepare to Make Final Mean >> Final](https://openjdk.org/jeps/500). >> >> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny >> when mutating a final instance field. JFR event r

Re: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final

2025-09-22 Thread Alan Bateman
On Mon, 22 Sep 2025 17:55:22 GMT, Chen Liang wrote: >> I mentioned this in the PR description because it is necessary to change a >> small number of tests ro run in /othervm mode. This is because jtreg >> reflectively opening a package isn't sufficient, it has to run the test with >> `--add-op

Re: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final

2025-09-22 Thread Alan Bateman
On Fri, 19 Sep 2025 13:13:22 GMT, Chen Liang wrote: >> Implementation changes for [JEP 500: Prepare to Make Final Mean >> Final](https://openjdk.org/jeps/500). >> >> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny >> when mutating a final instance field. JFR event r

Re: RFR: 8364361: [process] java.lang.Process should implement Closeable [v9]

2025-09-22 Thread Alan Bateman
On Fri, 19 Sep 2025 21:18:03 GMT, Roger Riggs wrote: >> The teardown of a Process launched by `ProcessBuilder` includes the closing >> of streams and ensuring the termination of the process is the responsibility >> of the caller. The `Process.close()` method provides a clear and obvious way >>

Re: RFR: 8368226: Remove Thread.stop [v2]

2025-09-22 Thread Alan Bateman
> JDK-8360979 is fixed then no change to KDC is needed. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the

Re: RFR: 8368226: Remove Thread.stop [v2]

2025-09-22 Thread Alan Bateman
On Mon, 22 Sep 2025 14:35:23 GMT, Roger Riggs wrote: >> Alan Bateman has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contain

Re: RFR: 8368226: Remove Thread.stop

2025-09-22 Thread Alan Bateman
On Mon, 22 Sep 2025 11:31:10 GMT, Mikhail Yankelevich wrote: >> The no-arg Thread.stop has been deprecated since JDK 1.2, deprecated for >> removal since JDK 18, and re-specified to throw UOE unconditionally since >> JDK 20. It is time to finally remove the method. Its more evil sibling >> Th

Re: RFR: 8364361: [process] java.lang.Process should implement Closeable [v9]

2025-09-22 Thread Alan Bateman
On Fri, 19 Sep 2025 21:18:03 GMT, Roger Riggs wrote: >> The teardown of a Process launched by `ProcessBuilder` includes the closing >> of streams and ensuring the termination of the process is the responsibility >> of the caller. The `Process.close()` method provides a clear and obvious way >>

Re: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final

2025-09-22 Thread Alan Bateman
On Sun, 11 May 2025 16:04:05 GMT, Chen Liang wrote: > For such a draft pull request, is the rename from "ignore" to the actual > issue title an indicator for starting a review for the overall design without > concerns about typos or bikeshedding? Skara adds the "rfr" label to PRs that are read

Re: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v8]

2025-09-20 Thread Alan Bateman
On Tue, 16 Sep 2025 10:06:21 GMT, David Beaumont wrote: >> Fair enough. I'll look at the callers and see if there's any route by which >> an "invalid" module name could appear. Though I already have to assume >> nobody uses "modules" or "packages" as the module name. > > It looks like ModuleDes

Re: RFR: 8367031: Regression in serialization of LocalDate class objects

2025-09-20 Thread Alan Bateman
On Wed, 17 Sep 2025 13:39:18 GMT, Roger Riggs wrote: > This reverts commit 4ced4e73fc0a517df826860839681004bb67e624. > > Restore the previous field types to maintain compatibility with previous > releases of the serialized form > of classes of java.time. > The classes reverted are LocalDate,

Re: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format [v4]

2025-09-19 Thread Alan Bateman
On Wed, 17 Sep 2025 00:32:37 GMT, Brian Burkhalter wrote: >> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of >> `canonicalize0` which causes the drive letter of a mapped drive to be >> converted to a UNC prefix. If such a substitution is detected, this request >> pr

Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v14]

2025-09-19 Thread Alan Bateman
On Wed, 10 Sep 2025 19:46:12 GMT, Kieran Farrell wrote: >> With the recent approval of UUIDv7 >> (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new >> static method UUID.timestampUUID() which constructs and returns a UUID in >> support of the new time generated UUID version

Re: RFR: 8367859: Remove nio exception gensrc

2025-09-18 Thread Alan Bateman
On Thu, 18 Sep 2025 16:17:24 GMT, Naoto Sato wrote: >> An alternative implementation to https://github.com/openjdk/jdk/pull/27338, >> which removes the entire gensrc stage and instead permanently checks in the >> generated Java files. > > src/java.base/share/classes/java/nio/charset/IllegalChar

Re: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format [v4]

2025-09-18 Thread Alan Bateman
On Wed, 17 Sep 2025 23:15:42 GMT, Brian Burkhalter wrote: > where `Z:` is mapped as `net use Z: \\localhost\c$\Temp`, in other words to > `C:\Temp`, a similar problem happens with `toRealPath`: > > ``` > jshell> Path.of("Z:\\target.txt").toRealPath() > $7 ==> Z:\target.txt > > jshell> Path.of(

Re: RFR: 8367859: Remove nio exception gensrc

2025-09-18 Thread Alan Bateman
On Thu, 18 Sep 2025 16:32:21 GMT, Naoto Sato wrote: >> I assume Magnus is using the generated classes and I think best to not >> change anything else with this update. We can follow-up yesterday for >> "opportunities" to modernize. > > OK fair enough. I just noticed that the file was modified,

Re: RFR: 8367859: Remove nio exception gensrc

2025-09-18 Thread Alan Bateman
On Wed, 17 Sep 2025 18:57:45 GMT, Magnus Ihse Bursie wrote: > An alternative implementation to https://github.com/openjdk/jdk/pull/27338, > which removes the entire gensrc stage and instead permanently checks in the > generated Java files. Can you confirm that tier1 + tier2 are passing? (most

Re: Add Multipath TCP (MPTCP) Support to the Java Networking API

2025-09-18 Thread Alan Bateman
he patch: Suggested-by: Alan Bateman I also included a test example for this option. All modifications can be found here: https://github.com/openjdk/jdk/compare/master...geliangtang:jdk:master Please provide any feedback or suggestions. As for the next steps, should I create a new issue for thi

Re: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format [v4]

2025-09-17 Thread Alan Bateman
On Wed, 17 Sep 2025 00:32:37 GMT, Brian Burkhalter wrote: >> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of >> `canonicalize0` which causes the drive letter of a mapped drive to be >> converted to a UNC prefix. If such a substitution is detected, this request >> pr

Re: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v5]

2025-09-17 Thread Alan Bateman
On Thu, 11 Sep 2025 15:59:54 GMT, David Beaumont wrote: >> Summary: Add two new methods to ImageReader to make SystemModuleReader more >> performant. >> >> Analysis of benchmarks shows that when the vast majority of resources >> (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in

Re: RFR: 8361950: Update to use jtreg 8 [v5]

2025-09-17 Thread Alan Bateman
On Wed, 17 Sep 2025 05:41:55 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the >> version of jtreg to use, for those systems that rely on this file. In >> addition, the requiredVers

Re: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format [v4]

2025-09-17 Thread Alan Bateman
On Wed, 17 Sep 2025 15:12:01 GMT, Brian Burkhalter wrote: > I had actually already been wondering whether the canonicalized path should > be checked for links before invoking `getFinalPath`. I assume you've checked the flags that can be provided to GetFinalPathNameByHandleW and that there isn

Re: RFR: 8367031: Regression in serialization of LocalDate class objects

2025-09-17 Thread Alan Bateman
On Wed, 17 Sep 2025 13:39:18 GMT, Roger Riggs wrote: > This reverts commit 4ced4e73fc0a517df826860839681004bb67e624. > > Restore the previous field types to maintain compatibility with previous > releases of the serialized form > of classes of java.time. > The classes reverted are LocalDate,

Re: RFR: 8367859: Remove shell script from nio exception gensrc

2025-09-17 Thread Alan Bateman
On Wed, 17 Sep 2025 10:17:33 GMT, Magnus Ihse Bursie wrote: > The only remaining shell script that is being used in the gensrc phase to > generate Java code is for the nio exceptions. This should be removed as well, > and replaced with a standard solution (Java buildtool or makefile API calls).

Re: RFR: 8361950: Update to use jtreg 8 [v5]

2025-09-16 Thread Alan Bateman
On Wed, 17 Sep 2025 06:43:20 GMT, Christian Stein wrote: >> make/autoconf/lib-tests.m4 line 31: >> >>> 29: >>> 30: # Minimum supported versions >>> 31: JTREG_MINIMUM_VERSION=8 >> >> Is the min version 8 or 8.2? (everywhere else in the PR suggests 8+2 so just >> curious). > > It's 8. The +2 re

Re: RFR: 8361950: Update to use jtreg 8 [v5]

2025-09-16 Thread Alan Bateman
On Wed, 17 Sep 2025 05:41:55 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the >> version of jtreg to use, for those systems that rely on this file. In >> addition, the requiredVers

Re: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v10]

2025-09-16 Thread Alan Bateman
On Tue, 16 Sep 2025 13:01:34 GMT, David Beaumont wrote: >> Summary: Add two new methods to ImageReader to make SystemModuleReader more >> performant. >> >> Analysis of benchmarks shows that when the vast majority of resources >> (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in

Re: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v8]

2025-09-16 Thread Alan Bateman
On Mon, 15 Sep 2025 21:33:15 GMT, David Beaumont wrote: >> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 381: >> >>> 379: /** Returns whether a resource exists in the given module. */ >>> 380: boolean containsResource(String moduleName, String >>> resourc

Re: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v8]

2025-09-15 Thread Alan Bateman
On Mon, 15 Sep 2025 21:38:29 GMT, David Beaumont wrote: >> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 360: >> >>> 358: // underlying jimage, but can only reliably return >>> resource nodes. >>> 359: if (moduleName.indexOf('/') >= 0) { >>> 360:

Re: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v9]

2025-09-15 Thread Alan Bateman
On Thu, 11 Sep 2025 12:13:04 GMT, Magnus Ihse Bursie wrote: >> In the static JDK image, a single humongous java executable is generated, >> and no other launcher, such as javac. This makes it impossible to run our >> jtreg tests, which assume these are present. >> >> The solution is fortunatel

Re: RFR: 8346719: Add relaunchers to the static JDK image for missing executables

2025-09-15 Thread Alan Bateman
On Thu, 3 Apr 2025 14:09:58 GMT, Alan Bateman wrote: >> In the static JDK image, a single humongous java executable is generated, >> and no other launcher, such as javac. This makes it impossible to run our >> jtreg tests, which assume these are present. >> >&g

Re: RFR: 8367597: Runtime.exit logging failed: Cannot invoke "java.lang.Module.getClassLoader()" because "m" is null [v3]

2025-09-14 Thread Alan Bateman
On Sat, 13 Sep 2025 09:35:54 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which addresses the issue noted in >> https://bugs.openjdk.org/browse/JDK-8367597? >> >> As noted in that issue, on certain occasions, during shutdown of the JVM, >> the logging in `Runtime.exit(

Re: RFR: 8367597: Runtime.exit logging failed: Cannot invoke "java.lang.Module.getClassLoader()" because "m" is null [v2]

2025-09-13 Thread Alan Bateman
On Sat, 13 Sep 2025 07:36:50 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which addresses the issue noted in >> https://bugs.openjdk.org/browse/JDK-8367597? >> >> As noted in that issue, on certain occasions, during shutdown of the JVM, >> the logging in `Runtime.exit(

Re: RFR: 8367597: Runtime.exit logging failed: Cannot invoke "java.lang.Module.getClassLoader()" because "m" is null [v2]

2025-09-13 Thread Alan Bateman
On Sat, 13 Sep 2025 07:33:50 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which addresses the issue noted in >> https://bugs.openjdk.org/browse/JDK-8367597? >> >> As noted in that issue, on certain occasions, during shutdown of the JVM, >> the logging in `Runtime.exit(

Re: RFR: 8367597: Runtime.exit logging failed: Cannot invoke "java.lang.Module.getClassLoader()" because "m" is null

2025-09-13 Thread Alan Bateman
On Sat, 13 Sep 2025 07:10:42 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which addresses the issue noted in > https://bugs.openjdk.org/browse/JDK-8367597? > > As noted in that issue, on certain occasions, during shutdown of the JVM, the > logging in `Runtime.exit()` ge

Re: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v8]

2025-09-12 Thread Alan Bateman
On Fri, 12 Sep 2025 12:08:35 GMT, David Beaumont wrote: >> Summary: Add two new methods to ImageReader to make SystemModuleReader more >> performant. >> >> Analysis of benchmarks shows that when the vast majority of resources >> (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in

Re: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v8]

2025-09-12 Thread Alan Bateman
On Fri, 12 Sep 2025 12:08:35 GMT, David Beaumont wrote: >> Summary: Add two new methods to ImageReader to make SystemModuleReader more >> performant. >> >> Analysis of benchmarks shows that when the vast majority of resources >> (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in

Re: RFR: 8366837: Clean up gensrc by spp.Spp

2025-09-11 Thread Alan Bateman
On Mon, 8 Sep 2025 18:06:54 GMT, Chen Liang wrote: > This patch removed the `VARHANDLES_GENSRC_DIR` variable used by > VarHandleGuards generation. I think it can be addressed by a hot fix. I think the change needs to backed out and the differences with line numbers checked to see what impact i

Re: RFR: 8367365: java/math/BigInteger/BigIntegerTest.java failed in jtreg timeout

2025-09-11 Thread Alan Bateman
On Thu, 11 Sep 2025 08:55:02 GMT, Raffaello Giulietti wrote: > This PR > * Moves sqrt() and nthRoot() tests to a new subset. > * Removes a leftover `@run` tag without a timeout. > * Increases the explicit timeout from 400 to 480. > * Sorts the jtreg tags according to standard conventions. test/

Re: RFR: 8346719: Add relaunchers to the static JDK image for missing executables

2025-09-10 Thread Alan Bateman
On Thu, 3 Apr 2025 14:09:58 GMT, Alan Bateman wrote: >> In the static JDK image, a single humongous java executable is generated, >> and no other launcher, such as javac. This makes it impossible to run our >> jtreg tests, which assume these are present. >> >&g

Re: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v4]

2025-09-07 Thread Alan Bateman
On Wed, 3 Sep 2025 12:08:49 GMT, Darragh Clarke wrote: > So I double checked the changes made there and wrote this up, I can make it > more precise or change wording if its going to be attached to a file. Package > info currently contains the script used to generate the code > > **Common chang

Re: Add Multipath TCP (MPTCP) Support to the Java Networking API

2025-09-07 Thread Alan Bateman
On 05/09/2025 09:43, Geliang Tang wrote: : 3. Proposed Java API Changes The goal is to allow Java applications to opt-in to using MPTCP when creating sockets, without breaking existing code. The proposed changes are additive and backward-compatible. The core idea is to add a boolean mptcp para

Re: RFR: 8361950: Update to use jtreg 8 [v4]

2025-09-06 Thread Alan Bateman
On Sat, 6 Sep 2025 01:04:56 GMT, Chen Liang wrote: > #26749 was merged 4 days ago. Can we integrate this one now? I think it would be useful to get input from @dholmes-ora and @lkorinth before doing this. There seems to be several timeout issues in the last few days, a few follow-on changes t

Re: RFR: 8366893: java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java timed out on macos-aarch64

2025-09-05 Thread Alan Bateman
On Fri, 5 Sep 2025 10:03:44 GMT, Aleksey Shipilev wrote: > Seeing these tests failing often now. I think I need a second reviewer to > integrate this, to make testing cleaner. One Reviewer is okay here. - PR Comment: https://git.openjdk.org/jdk/pull/27104#issuecomment-3257874725

Re: RFR: 8366893: java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java timed out on macos-aarch64

2025-09-05 Thread Alan Bateman
On Thu, 4 Sep 2025 15:47:33 GMT, Aleksey Shipilev wrote: > GetStackTraceALotWhenPinned test times out every so often in GHA. > > The last sightings are on macos-aarch64: > > > 2025-09-04T10:41:29.357879Z => 87894 of 10 > 2025-09-04T10:41:30.365534Z => 88105 of 10 > Timeout signalled af

Re: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods

2025-09-04 Thread Alan Bateman
On Thu, 4 Sep 2025 06:36:20 GMT, Volkan Yazici wrote: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` > failures, and hence, backed out in [JDK-8366693] (#27050). This PR > reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.o

Re: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods

2025-09-04 Thread Alan Bateman
On Thu, 4 Sep 2025 06:36:20 GMT, Volkan Yazici wrote: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` > failures, and hence, backed out in [JDK-8366693] (#27050). This PR > reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.o

Re: RFR: 8366102: Clarification Needed: Symbolic Link Handling in File API Specifications [v5]

2025-09-03 Thread Alan Bateman
On Wed, 3 Sep 2025 17:10:41 GMT, Brian Burkhalter wrote: >> Attempt to improve the verbiage of the `java.io.File` specification to make >> it clearer whether a given method operates only on an abstract pathname or >> on the actual file system entry it denotes. > > Brian Burkhalter has updated t

Re: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v4]

2025-09-03 Thread Alan Bateman
On Wed, 3 Sep 2025 15:00:22 GMT, Darragh Clarke wrote: > I could try just replicating the existing code instead of using the generated > method? We always use the ident as an fd so don't use the full width. It doesn't matter if KQueue uses int fd or long ident in the API that it exposes but I'

Re: RFR: 8366400: JCK test api/java_text/DecimalFormat/Parse.html fails after JDK-8363972 [v2]

2025-09-03 Thread Alan Bateman
On Tue, 2 Sep 2025 22:15:29 GMT, Justin Lu wrote: >> This PR addresses a JCK test failure of an unexpected SIOOBE during >> DecimalFormat parsing. During the char by char comparison in `matchAffix`, >> the minimum of the length of the parsed String and the PP index + affix >> length are iterat

Re: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 [v4]

2025-09-03 Thread Alan Bateman
On Tue, 2 Sep 2025 21:21:04 GMT, Justin Lu wrote: >> This PR addresses a JCK test failure related to `DecimalFormatSymbols` >> de-serialization. While the current public API of DFS disallows a null >> locale, it was possible to set in the past. Thus, the >> `loadNumberData(locale)` call curren

Re: MethodHandles.lookup errors where publicLookup is ok

2025-09-03 Thread Alan Bateman
On 02/09/2025 20:36, Charles Oliver Nutter wrote: However... why doesn't `findVirtual()` request read access to the given class's module before erroring? Presumably this is what the reflected call and the `publicLookup()` logic does. Worst case, it would raise an error because it cannot gain

Re: MethodHandles.lookup errors where publicLookup is ok

2025-09-03 Thread Alan Bateman
On 02/09/2025 17:22, Charles Oliver Nutter wrote: > publicLookup has UNCONDITIONAL access so it assumes readability (like > core reflection). The lookup object obtained with MethodsHandles.lookup > does not so there may be cases where the caller needs to use > Module.addReads to add the read edg

Re: RFR: 8366102: Clarification Needed: Symbolic Link Handling in File API Specifications [v4]

2025-09-02 Thread Alan Bateman
On Tue, 2 Sep 2025 20:23:26 GMT, Brian Burkhalter wrote: >> Attempt to improve the verbiage of the `java.io.File` specification to make >> it clearer whether a given method operates only on an abstract pathname or >> on the actual file system entry it denotes. > > Brian Burkhalter has updated t

Re: MethodHandles.lookup errors where publicLookup is ok

2025-09-02 Thread Alan Bateman
On 02/09/2025 16:31, Charles Oliver Nutter wrote: I've run into various versions of this situation and I wonder if my expectations about MethodHandles.lookup vs publicLookup are flawed. This issue shows an IllegalAccessException "symbolic reference class is not accessible: class jdk.proxy4.

Re: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build

2025-09-02 Thread Alan Bateman
On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has > conflicting changes with JDK-8362893 slightly preceding it. Back out > JDK-8356439 by reverting eea50fbc1b2. Marked as reviewed by alanb (Reviewer). -

Re: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v11]

2025-09-02 Thread Alan Bateman
On Mon, 1 Sep 2025 16:16:23 GMT, Volkan Yazici wrote: >> `NoRepl`-suffixed `String` methods denote methods that do not replace >> invalid characters, but throw `CharacterCodingException` on encounter. This >> behavior cannot easily be derived from the method footprints, has been a >> source of

Re: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v4]

2025-09-02 Thread Alan Bateman
On Tue, 2 Sep 2025 07:18:54 GMT, Per Minborg wrote: > I think we could document the changes where we document how jextract is run. > Ideally, we spoke about `sed` but maybe a more informal description can be > made? That might be okay. In the distant past the in-tree copy of the zlib code nee

Re: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9]

2025-09-01 Thread Alan Bateman
On Mon, 1 Sep 2025 13:21:49 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add >> timeouts to individual test cases so that I am able to run them with a >> timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to chan

Re: RFR: 8361950: Update to use jtreg 8 [v3]

2025-08-30 Thread Alan Bateman
On Sat, 30 Aug 2025 05:27:47 GMT, Christian Stein wrote: > > Is there an ETA for integration? > > On September, 1st. I had a brief discussion with Christian about maybe holding off until the TIMEOUT_FACTOR changes (pull/26749) is integrated. - PR Comment: https://git.openjdk.org/

Re: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v4]

2025-08-30 Thread Alan Bateman
On Fri, 29 Aug 2025 14:50:29 GMT, Per Minborg wrote: >> src/java.base/macosx/classes/sun/nio/ch/KQueue.java line 91: >> >>> 89: */ >>> 90: static MemorySegment getEvent(MemorySegment memoryHandle, int i) { >>> 91: return kevent.asSlice(memoryHandle, i); >> >> Previous work elim

Re: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v10]

2025-08-30 Thread Alan Bateman
On Fri, 29 Aug 2025 13:48:52 GMT, Volkan Yazici wrote: >> `NoRepl`-suffixed `String` methods denote methods that do not replace >> invalid characters, but throw `CharacterCodingException` on encounter. This >> behavior cannot easily be derived from the method footprints, has been a >> source o

Re: RFR: 8366102: Clarification Needed: Symbolic Link Handling in File API Specifications [v2]

2025-08-30 Thread Alan Bateman
On Fri, 29 Aug 2025 16:27:35 GMT, Brian Burkhalter wrote: >> Attempt to improve the verbiage of the `java.io.File` specification to make >> it clearer whether a given method operates only on an abstract pathname or >> on the actual file system entry it denotes. > > Brian Burkhalter has updated

Re: RFR: 8366400: JCK test api/java_text/DecimalFormat/Parse.html fails after JDK-8363972

2025-08-29 Thread Alan Bateman
On Fri, 29 Aug 2025 23:59:54 GMT, Justin Lu wrote: > This PR addresses a JCK test failure of an unexpected SIOOBE during > DecimalFormat parsing. During the char by char comparison in `matchAffix`, > the minimum of the length of the parsed String and the PP index + affix > length are iterated

Re: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972

2025-08-29 Thread Alan Bateman
On Fri, 29 Aug 2025 18:00:25 GMT, Justin Lu wrote: > This PR addresses a JCK test failure related to `DecimalFormatSymbols` > de-serialization. While the current public API of DFS disallows a null > locale, it was possible to set in the past. Thus, the > `loadNumberData(locale)` call currently

Re: RFR: 8366102: Clarification Needed: Symbolic Link Handling in File API Specifications

2025-08-29 Thread Alan Bateman
On Fri, 29 Aug 2025 15:01:51 GMT, Brian Burkhalter wrote: > Attempt to improve the verbiage of the `java.io.File` specification to make > it clearer whether a given method operates only on an abstract pathname or on > the actual file system entry it denotes. src/java.base/share/classes/java/io

Re: RFR: 8365467: Fix multiple issues in ExplodedImage [v2]

2025-08-29 Thread Alan Bateman
On Fri, 29 Aug 2025 08:49:27 GMT, David Beaumont wrote: >> This PR addresses several issues found while adding unit tests for >> ExplodedImage. >> I have added review comments for changes (some of which are a little >> preferential, but bring the code into line with things like ImageReader in

Re: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v9]

2025-08-28 Thread Alan Bateman
On Thu, 28 Aug 2025 19:25:10 GMT, Volkan Yazici wrote: >> `NoRepl`-suffixed `String` methods denote methods that do not replace >> invalid characters, but throw `CharacterCodingException` on encounter. This >> behavior cannot easily be derived from the method footprints, has been a >> source o

Re: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v2]

2025-08-28 Thread Alan Bateman
On Tue, 19 Aug 2025 13:20:17 GMT, Darragh Clarke wrote: >> Darragh Clarke has updated the pull request incrementally with one >> additional commit since the last revision: >> >> implementing feedback, adding missing errno checks, cleanup > > I made a few changes mostly based on comments but I

Re: RFR: 8365898: Specification of java.lang.module.ModuleDescriptor.packages() method can be improved [v3]

2025-08-28 Thread Alan Bateman
On Tue, 26 Aug 2025 05:37:49 GMT, Jaikiran Pai wrote: >> Can I please get a review of this trivial change to the >> `ModuleDescriptor.packages()` method's specification? >> >> The change here clarifies that this method returns all packages that belong >> to the module and not just those that a

Re: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v4]

2025-08-28 Thread Alan Bateman
On Thu, 28 Aug 2025 08:51:14 GMT, Darragh Clarke wrote: >> This PR aims to Panamize the Java Kqueue implementation, This is based on >> the work that was previously shared in >> https://github.com/openjdk/jdk/pull/22307 , The main change since then is >> that this branch takes advantage of the

Re: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v4]

2025-08-28 Thread Alan Bateman
On Thu, 28 Aug 2025 08:51:14 GMT, Darragh Clarke wrote: >> This PR aims to Panamize the Java Kqueue implementation, This is based on >> the work that was previously shared in >> https://github.com/openjdk/jdk/pull/22307 , The main change since then is >> that this branch takes advantage of the

Re: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v3]

2025-08-28 Thread Alan Bateman
On Wed, 27 Aug 2025 08:44:19 GMT, Per Minborg wrote: >> Darragh Clarke has updated the pull request incrementally with one >> additional commit since the last revision: >> >> moved repeating code into own method > > src/java.base/macosx/classes/sun/nio/ch/KQueuePoller.java line 76: > >> 74:

Re: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v4]

2025-08-28 Thread Alan Bateman
On Thu, 28 Aug 2025 08:51:14 GMT, Darragh Clarke wrote: >> This PR aims to Panamize the Java Kqueue implementation, This is based on >> the work that was previously shared in >> https://github.com/openjdk/jdk/pull/22307 , The main change since then is >> that this branch takes advantage of the

Re: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v8]

2025-08-28 Thread Alan Bateman
On Thu, 28 Aug 2025 10:46:01 GMT, Volkan Yazici wrote: >> `NoRepl`-suffixed `String` methods denote methods that do not replace >> invalid characters, but throw `CharacterCodingException` on encounter. This >> behavior cannot easily be derived from the method footprints, has been a >> source o

Re: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v8]

2025-08-28 Thread Alan Bateman
On Thu, 28 Aug 2025 10:46:01 GMT, Volkan Yazici wrote: >> `NoRepl`-suffixed `String` methods denote methods that do not replace >> invalid characters, but throw `CharacterCodingException` on encounter. This >> behavior cannot easily be derived from the method footprints, has been a >> source o

Re: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v8]

2025-08-28 Thread Alan Bateman
On Thu, 28 Aug 2025 10:46:01 GMT, Volkan Yazici wrote: >> `NoRepl`-suffixed `String` methods denote methods that do not replace >> invalid characters, but throw `CharacterCodingException` on encounter. This >> behavior cannot easily be derived from the method footprints, has been a >> source o

Re: [jdk25] RFR: 8361497: Scoped Values: orElse and orElseThrow do not access the cache

2025-08-28 Thread Alan Bateman
On Thu, 28 Aug 2025 01:14:20 GMT, Rui Li wrote: > Backport of https://bugs.openjdk.org/browse/JDK-8361497 > > Not clean due to the lack of https://bugs.openjdk.org/browse/JDK-8360884. The > cherry pick conflict was caused by the a new test added in the JDK-8360884., > [code](https://github.com

Re: RFR: 8366255: Remove 'package_to_module' function from imageFile.cpp

2025-08-27 Thread Alan Bateman
On Wed, 27 Aug 2025 19:05:10 GMT, Coleen Phillimore wrote: > It's not really hotspot-runtime code unless @dholmes-ora knows anything about > it. Change to libjimage usually need eyes from both core-libs and hotspot-runtime, the latter due to the usage in classLoader.cpp. - PR Com

Re: RFR: 8366131: ProblemList java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java

2025-08-26 Thread Alan Bateman
On Tue, 26 Aug 2025 05:39:43 GMT, Johny Jose wrote: > Problem listing the test case till the fix for JDK-8365398 approved and > integrated Marked as reviewed by alanb (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/26937#pullrequestreview-3155168521

Re: RFR: 7191877: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently

2025-08-26 Thread Alan Bateman
On Wed, 6 Aug 2025 10:29:45 GMT, Johny Jose wrote: > The test was problem listed since jdk8 as intermittent failures were > observed. For all the failed scenarios, number of objects left in leaseTable > were less than or equal to 4. Though for most of the runs the number of > objects left is l

Re: RFR: 8365898: Specification of java.lang.module.ModuleDescriptor.packages() method can be improved [v3]

2025-08-26 Thread Alan Bateman
On Tue, 26 Aug 2025 05:54:27 GMT, Jaikiran Pai wrote: > and it does indeed return all the packages. If not the JVMS text, perhaps the > API specification of > `java.lang.classfile.attribute.ModulePackagesAttribute.packages()` method can > be simplified to say that it returns all packages? Perh

Re: RFR: 8365898: Specification of java.lang.module.ModuleDescriptor.packages() method can be improved [v2]

2025-08-25 Thread Alan Bateman
On Tue, 26 Aug 2025 00:42:52 GMT, Jaikiran Pai wrote: >> Can I please get a review of this trivial change to the >> `ModuleDescriptor.packages()` method's specification? >> >> The change here clarifies that this method returns all packages that belong >> to the module and not just those that a

Re: RFR: 8365885: Clean up constant pool reflection native code

2025-08-25 Thread Alan Bateman
On Wed, 20 Aug 2025 21:29:29 GMT, Chen Liang wrote: > When I was trying to reuse this constant pool reflection for assembly phase > indy argument validation, I noted the JNI code has a lot of confusing > arguments. In particular, the JVM_ConstantPoolGetSize is wrong because of > argument confu

Re: RFR: 8365898: Specification of java.lang.module.ModuleDescriptor.packages() method can be improved

2025-08-25 Thread Alan Bateman
On Mon, 25 Aug 2025 13:19:29 GMT, Jaikiran Pai wrote: > Can I please get a review of this trivial change to the > `ModuleDescriptor.packages()` method's specification? > > The change here clarifies that this method returns all packages that belong > to the module and not just those that are ex

Integrated: 8365893: test/jdk/java/lang/Thread/virtual/JfrEvents.java failing intermittently

2025-08-24 Thread Alan Bateman
On Sun, 24 Aug 2025 07:59:05 GMT, Alan Bateman wrote: > Under load conditions, testVirtualThreadStartAndEnd can fail because the JFR > recording doesn't have a VirtualThreadEndEvent recorded for all virtual > threads. This is a test issue. ExecutorService::close waits for all

Re: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]

2025-08-24 Thread Alan Bateman
On Fri, 22 Aug 2025 18:43:29 GMT, Albert Mingkun Yang wrote: >>> @prrace the change maintains the same absolute timeout value for those >>> tests. Before the default of 120 was multiplied by the timeoutFactor of 4 >>> to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to >

Re: Proposal: Add getRandom() default method to java.util.List

2025-08-24 Thread Alan Bateman
On 23/08/2025 20:36, Daniel Tavares wrote: : *Proposed Method* default T getRandom() {     if (isEmpty()) return null;     int index = ThreadLocalRandom.current().nextInt(size());     return get(index); } Add Lists that are mutable and support concurrent access to your list to think about. Th

RFR: 8365893: test/jdk/java/lang/Thread/virtual/JfrEvents.java failing intermittently

2025-08-24 Thread Alan Bateman
Under load conditions, testVirtualThreadStartAndEnd can fail because the JFR recording doesn't have a VirtualThreadEndEvent recorded for all virtual threads. This is a test issue. ExecutorService::close waits for all tasks (not threads) to finish. For ThreadPerTaskExecutor the thread terminates

Re: RFR: 8364361: [process] java.lang.Process should implement close and be AutoCloseable [v4]

2025-08-20 Thread Alan Bateman
On Thu, 21 Aug 2025 03:10:23 GMT, David Holmes wrote: >> Maybe there is a cleaner overall solution that doesn't require locking >> `this` at all... ? >> >> For example... just brainstorming, this is not fully baked and probably >> outside of the scope of this PR... >> * Use `AtomicReference.ge

Re: RFR: 8361613: System.console() should only be available for interactive terminal [v3]

2025-08-20 Thread Alan Bateman
On Mon, 14 Jul 2025 20:23:25 GMT, Naoto Sato wrote: >> In prior JDK releases, `System.console()` could return a `Console` instance >> even when the JVM was not attached to an interactive terminal. This could >> lead to confusion, particularly when input was not from a keyboard or output >> was

Re: RFR: 8361613: System.console() should only be available for interactive terminal [v3]

2025-08-20 Thread Alan Bateman
On Tue, 15 Jul 2025 16:26:13 GMT, Naoto Sato wrote: >> we do have wordings like " If the virtual machine is started from an >> interactive command line without redirecting the standard input AND output >> streams then its console will exist ..." and "If no console device is >> available then an

Integrated: 8365671: Typo in Joiner.allUntil example

2025-08-20 Thread Alan Bateman
On Wed, 20 Aug 2025 09:17:35 GMT, Alan Bateman wrote: > Fix two typos in one of the examples in Joiner.allUntil's API. (We may > re-visit the example in a future update, for now, just the typos). This pull request has now been integrated. Changeset: be6c15ec Author:Alan B

  1   2   3   4   5   6   7   8   9   10   >