Re: RFR: 8354053: Remove unused JavaIOFilePermissionAccess

On Sun, 13 Apr 2025 20:01:28 GMT, Weijun Wang wrote: > I remember the implies method of the file permission class depends on whether > this system property is set. Although file permission is no longer used in > access control check the class and the method are still there. Right, and I wasn't

Re: RFR: 8354053: Remove unused JavaIOFilePermissionAccess

On Sun, 13 Apr 2025 20:01:28 GMT, Weijun Wang wrote: > I remember the implies method of the file permission class depends on whether > this system property is set. Although file permission is no longer used in > access control check the class and the method are still there. Right, and I wasn't

Re: RFR: 8354053: Remove unused JavaIOFilePermissionAccess

On Fri, 11 Apr 2025 21:26:08 GMT, Roger Riggs wrote: > The JavaIOFilePermissionAccess interface is removed from SharedSecrets and > its implementation (FilePermCompat.java) used by the test is moved to java.io > FilePermission where cross package access is not needed. > The test FilePermission

Re: RFR: 8354053: Remove unused JavaIOFilePermissionAccess

On Fri, 11 Apr 2025 21:26:08 GMT, Roger Riggs wrote: > The JavaIOFilePermissionAccess interface is removed from SharedSecrets and > its implementation (FilePermCompat.java) used by the test is moved to java.io > FilePermission where cross package access is not needed. > The test FilePermission

Re: RFR: 8349716: IllegalAccessError when Proxy methods return object of a package-private type

On Sun, 13 Apr 2025 09:49:46 GMT, Chen Liang wrote: > Proxy currently places proxy classes that proxy interfaces with > package-private return types in dynamic modules. This means that if a return > value is non-null, Proxy cannot return it and throws IllegalAccessError. > > This patch changes

Re: RFR: 8353013: java.net.URI.create(String) may have low performance to scan the host/domain name from URI string when the hostname starts with number

On Fri, 28 Mar 2025 15:19:46 GMT, Rohitash wrote: > `scanByte` throws `NumberFormatException` for URIs that start with numbers, > e.g., https://.x.y/ > The current flow is `parseIPv4Address` → `scanIPv4Address` → `scanByte`. > `parseIPv4Address` uses `NumberFormatException` for control

Re: RFR: 8354320: Changes to jpackage.md cause pandoc warning [v3]

On Fri, 11 Apr 2025 13:50:04 GMT, Alexey Semenyuk wrote: >> Escape the dollar sign. > > Alexey Semenyuk has updated the pull request incrementally with one > additional commit since the last revision: > > Disable tex_math_dollars extension Thanks for getting this to the right place. ---

Re: RFR: 8343157: Examine large files for character encoding/decoding

On Fri, 11 Apr 2025 17:02:13 GMT, Naoto Sato wrote: > Removing old charset test cases that verify new charset implementations (as > of JDK7). Removed tests/files are actual charset implementations used in > pre-JDK7, which have been used for comparing the results. Since those "new" > implement

Re: RFR: 8343157: Examine large files for character encoding/decoding

On Fri, 11 Apr 2025 17:02:13 GMT, Naoto Sato wrote: > Removing old charset test cases that verify new charset implementations (as > of JDK7). Removed tests/files are actual charset implementations used in > pre-JDK7, which have been used for comparing the results. Since those "new" > implement

Re: RFR: 8353642: Deprecate networking permission classes for removal [v2]

On Fri, 11 Apr 2025 11:30:54 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/java/net/HttpURLConnection.java line 617: >> >>> 615: * {@link java.security.AllPermission}. >>> 616: */ >>> 617: @Deprecated(since = "25") >> >> can this (and all other getPermission methods) be

Re: RFR: 8353642: Deprecate networking permission classes for removal [v2]

On Fri, 11 Apr 2025 11:30:54 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/java/net/HttpURLConnection.java line 617: >> >>> 615: * {@link java.security.AllPermission}. >>> 616: */ >>> 617: @Deprecated(since = "25") >> >> can this (and all other getPermission methods) be

Re: RFR: 8342486: Implement JEP draft: Structured Concurrency (Fifth Preview) [v7]

k.shutdown > and wakeup methods are no longer confined. The STS API implementation moves > to non-public StructuedTaskScopeImpl because STS is now an interface. A > non-public Joiners class is added with the built-in Joiner implementations. Alan Bateman has updated the pull request with

Re: RFR: 8354320: Changes to jpackage.md cause pandoc warning

On Thu, 10 Apr 2025 21:50:10 GMT, Alexey Semenyuk wrote: > Escape the dollar sign. Thanks for jumping on this. - Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24585#pullrequestreview-2759425326

Re: RFR: 8354189: Remove JLI_ReportErrorMessageSys on Windows [v2]

On Fri, 11 Apr 2025 07:11:19 GMT, Matthias Baesken wrote: >> JLI_ReportErrorMessageSys is not used any more on Windows, so we can remove >> it and make it UNIX-only (there a still a few remaining usages). > > Matthias Baesken has updated the pull request incrementally with one > additional comm

Re: RFR: 8353185: Introduce the concept of upgradeable files in context of JEP 493 [v4]

On Mon, 7 Apr 2025 13:35:57 GMT, Severin Gehwolf wrote: >> For JEP 493-enabled builds there are no JMODs. Certain files come from the >> installed JDK image when a user creates a custom run-time from it. This is >> problematic for example for files that often come from a different package >> (

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

On 08/04/2025 13:51, Engebretson, John wrote:   Brian, Alan, Markus, Chen – thank you for your feedback on this issue!  At this point we seem to agree that 1) there is merit to this idea, 2) nobody loves a new public class (including me), and 3) this is not a subclass of ByteArrayOutputStream

RFR: 8351927: Change VirtualThread implementation to use use FJP delayed task handling

Follow up to JDK-8319447 to change the VirtualThread implementation to use FJP's delayed task handling. The SPTE based implementation is not removed. It will continue to be used by tests. If custom schedulers are exposed in the future then they will use this implementation. For timed-Object.wa

Re: RFR: 8344708: Compiler Implementation of Module Import Declarations [v5]

On Thu, 10 Apr 2025 18:04:54 GMT, Jan Lahoda wrote: >> This is a patch to finalize the module imports feature. Please see: >> https://bugs.openjdk.org/browse/JDK-8344700 > > Jan Lahoda has updated the pull request incrementally with one additional > commit since the last revision: > > Reflect

Re: RFR: 8354189: Remove JLI_ReportErrorMessageSys on Windows

On Thu, 10 Apr 2025 08:03:58 GMT, Matthias Baesken wrote: > JLI_ReportErrorMessageSys is not used any more on Windows, so we can remove > it and make it UNIX-only (there a still a few remaining usages). I think this looks okay, can you update the copyright header dates before you integrate. -

Re: RFR: 8353185: Introduce the concept of upgradeable files in context of JEP 493 [v5]

On Wed, 9 Apr 2025 16:10:20 GMT, Severin Gehwolf wrote: >> For JEP 493-enabled builds there are no JMODs. Certain files come from the >> installed JDK image when a user creates a custom run-time from it. This is >> problematic for example for files that often come from a different package >> (

Re: RFR: 8353185: Introduce the concept of upgradeable files in context of JEP 493 [v5]

On Wed, 9 Apr 2025 16:10:20 GMT, Severin Gehwolf wrote: >> For JEP 493-enabled builds there are no JMODs. Certain files come from the >> installed JDK image when a user creates a custom run-time from it. This is >> problematic for example for files that often come from a different package >> (

Re: RFR: 8353185: Introduce the concept of upgradeable files in context of JEP 493 [v4]

On Tue, 8 Apr 2025 13:31:10 GMT, Severin Gehwolf wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/LinkableRuntimeImage.java >> line 71: >> >>> 69: private static InputStream getDiffInputStream(String module) throws >>> IOException { >>> 70: String resourceName = Strin

Re: RFR: 8353185: Introduce the concept of upgradeable files in context of JEP 493 [v4]

On Tue, 8 Apr 2025 13:31:10 GMT, Severin Gehwolf wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/LinkableRuntimeImage.java >> line 71: >> >>> 69: private static InputStream getDiffInputStream(String module) throws >>> IOException { >>> 70: String resourceName = Strin

Re: RFR: 8351740: Clean up some code around initialization of encoding properties [v2]

On Mon, 7 Apr 2025 23:43:29 GMT, Stuart Marks wrote: >> Some of the code that creates various encoding properties at JVM >> initialization time, such as file.encoding and native.encoding, could use >> some cleaning up. Cleanup is fairly minimal and should be mostly >> behavior-preserving. Chan

Re: RFR: 8352728: InternalError loading java.security due to Windows parent folder permissions

On Sat, 5 Apr 2025 02:36:43 GMT, Francisco Ferrari Bihurriet wrote: > Hi, this is a proposal to fix 8352728. > > The main idea is to replace > [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOp

Re: RFR: 8344708: Compiler Implementation of Module Import Declarations [v4]

On Wed, 2 Apr 2025 16:59:16 GMT, Jan Lahoda wrote: >> This is a patch to finalize the module imports feature. Please see: >> https://bugs.openjdk.org/browse/JDK-8344700 > > Jan Lahoda has updated the pull request incrementally with one additional > commit since the last revision: > > Reflecti

Re: RFR: 8353938: hotspot/jtreg/serviceability/dcmd/jvmti/LoadAgentDcmdTest.java fails on static JDK [v2]

On Tue, 8 Apr 2025 19:09:02 GMT, Jiangli Zhou wrote: >> Please review this PR that changes >> `LoadAgentDcmdTest.getLibInstrumentPath()` to not locate `libinstrument` >> shared library if running on static JDK, instead just returns >> "libinstrument." directly. Both test case #1 and #2 in >>

Re: RFR: 8353938: hotspot/jtreg/serviceability/dcmd/jvmti/LoadAgentDcmdTest.java fails on static JDK [v3]

On Wed, 9 Apr 2025 17:14:27 GMT, Jiangli Zhou wrote: >> Please review this PR that changes >> `LoadAgentDcmdTest.getLibInstrumentPath()` to not locate `libinstrument` >> shared library if running on static JDK, instead just returns >> "libinstrument." directly. Both test case #1 and #2 in >>

Re: RFR: 8354111: JavaDoc states that Iterator.remove() is linear in the LinkedBlockingDeque

On Tue, 8 Apr 2025 08:50:37 GMT, kabutz wrote: > One of the features of the LinkedBlockingDeque is that it is a doubly-linked > node queue, with pointers in each node to "prev" and "next", which allows > remove() in the Iterator to remove the node in constant time. However, in the > JavaDoc of

Integrated: 8351927: Change VirtualThread implementation to use use FJP delayed task handling

On Thu, 13 Mar 2025 10:48:14 GMT, Alan Bateman wrote: > Follow up to JDK-8319447 to change the VirtualThread implementation to use > FJP's delayed task handling. > > The SPTE based implementation is not removed. It will continue to be used by > tests. If custom scheduler

Integrated: 8351927: Change VirtualThread implementation to use use FJP delayed task handling

On Thu, 13 Mar 2025 10:48:14 GMT, Alan Bateman wrote: > Follow up to JDK-8319447 to change the VirtualThread implementation to use > FJP's delayed task handling. > > The SPTE based implementation is not removed. It will continue to be used by > tests. If custom scheduler

Re: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods [v3]

On Mon, 7 Apr 2025 21:07:36 GMT, Jan Lahoda wrote: >> This is a PR that implements JEP: Compact Source Files and Instance Main >> Methods. Changes include: >> - `java.io.IO` moved to `java.lang.IO`, and no longer uses >> `System.console()` to implement the methods (thanks to @stuart-marks) >> -

Re: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods [v3]

On Mon, 7 Apr 2025 18:28:21 GMT, Stuart Marks wrote: >> Someone is bound to ask why the readln method throw but the println methods >> don't. > > The IOError was carried over from Console.readLine(), which throws IOError on > error. Of course we're decoupled from Console now, but that was the o

Re: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods [v3]

On Mon, 7 Apr 2025 21:07:36 GMT, Jan Lahoda wrote: >> This is a PR that implements JEP: Compact Source Files and Instance Main >> Methods. Changes include: >> - `java.io.IO` moved to `java.lang.IO`, and no longer uses >> `System.console()` to implement the methods (thanks to @stuart-marks) >> -

Re: RFR: 8352773: JVMTI should disable events during java upcalls

On Wed, 9 Apr 2025 08:14:04 GMT, Serguei Spitsyn wrote: > As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI > `GetThreadGroupChildren` does an upcall to java. This results in > a`ClassPrepare` event the first time it does this, and these events can cause > problems

Re: RFR: 8351927: Change VirtualThread implementation to use use FJP delayed task handling

On Wed, 9 Apr 2025 08:03:44 GMT, Viktor Klang wrote: >> It already does, no CAS if the current value is the new value. > > I meant the park permit. :) getAndSetParkPermit isn't changed in this PR. If the park permit is already granted then getAndSetParkPermit(true) doesn't do anything. More gen

Re: RFR: 8351927: Change VirtualThread implementation to use use FJP delayed task handling

On Wed, 9 Apr 2025 08:03:44 GMT, Viktor Klang wrote: >> It already does, no CAS if the current value is the new value. > > I meant the park permit. :) getAndSetParkPermit isn't changed in this PR. If the park permit is already granted then getAndSetParkPermit(true) doesn't do anything. More gen

Re: RFR: 8353888: Implement Key Derivation Function API [v2]

On Tue, 8 Apr 2025 21:03:18 GMT, Chen Liang wrote: >> Oh, I didn't know that. I've built this with JDK 24 as the boot JDK and see >> no problem. > > I think the dependency is in the CreateSymbols tool or something Yes, we've had issues with boot cycle builds at least, Jan has the details and I

Re: RFR: 8353888: Implement Key Derivation Function API [v2]

On Tue, 8 Apr 2025 21:03:18 GMT, Chen Liang wrote: >> Oh, I didn't know that. I've built this with JDK 24 as the boot JDK and see >> no problem. > > I think the dependency is in the CreateSymbols tool or something Yes, we've had issues with boot cycle builds at least, Jan has the details and I

Re: RFR: 8351927: Change VirtualThread implementation to use use FJP delayed task handling

On Tue, 8 Apr 2025 20:05:26 GMT, Viktor Klang wrote: >> Follow up to JDK-8319447 to change the VirtualThread implementation to use >> FJP's delayed task handling. >> >> The SPTE based implementation is not removed. It will continue to be used by >> tests. If custom schedulers are exposed in th

Re: RFR: 8351927: Change VirtualThread implementation to use use FJP delayed task handling

On Tue, 8 Apr 2025 20:05:26 GMT, Viktor Klang wrote: >> Follow up to JDK-8319447 to change the VirtualThread implementation to use >> FJP's delayed task handling. >> >> The SPTE based implementation is not removed. It will continue to be used by >> tests. If custom schedulers are exposed in th

Re: RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer [v5]

On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG wrote: >> This Pull Request proposes an implementation for >> [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new >> method `public void getChars(int srcBegin, int srcEnd, char[] dst, int >> dstBegin)` to the `CharSequence` i

RFR: 8351927: Change VirtualThread implementation to use use FJP delayed task handling

Follow up to JDK-8319447 to change the VirtualThread implementation to use FJP's delayed task handling. The SPTE based implementation is not removed. It will continue to be used by tests. If custom schedulers are exposed in the future then they will use this implementation. For timed-Object.wa

Re: RFR: 8353641: Deprecate core library permission classes for removal [v8]

On Mon, 7 Apr 2025 18:40:35 GMT, Roger Riggs wrote: >> Now that the Security Manager is permanently disabled, the following >> permission classes in the core libraries area can be deprecated for removal >> as they are no longer useful: FilePermission, LinkPermission, >> LoggingPermission, Prop

Integrated: 8353267: jmod create finds the wrong set of packages when class file are in non-package location

On Tue, 1 Apr 2025 17:33:43 GMT, Alan Bateman wrote: > `jmod create` maps the contents of the module to a set of packages. This > mapping derives illegal package names when class resources are located in > non-package locations, e.g. in the META-INF tree. `jlink` also has an issue

Re: RFR: 8354016: Update ReentrantReadWriteLock documentation to reflect its new max capacity [v2]

On Tue, 8 Apr 2025 10:11:45 GMT, Viktor Klang wrote: >> Updating the ReentrantReadWriteLock documentation > > Viktor Klang has updated the pull request incrementally with one additional > commit since the last revision: > > Update > src/java.base/share/classes/java/util/concurrent/locks/Reen

Re: RFR: 8353641: Deprecate core library permission classes for removal [v8]

On Mon, 7 Apr 2025 18:40:35 GMT, Roger Riggs wrote: >> Now that the Security Manager is permanently disabled, the following >> permission classes in the core libraries area can be deprecated for removal >> as they are no longer useful: FilePermission, LinkPermission, >> LoggingPermission, Prop

Re: RFR: 8353641: Deprecate core library permission classes for removal [v8]

On Mon, 7 Apr 2025 18:40:35 GMT, Roger Riggs wrote: >> Now that the Security Manager is permanently disabled, the following >> permission classes in the core libraries area can be deprecated for removal >> as they are no longer useful: FilePermission, LinkPermission, >> LoggingPermission, Prop

Re: RFR: 8353185: Introduce the concept of upgradeable files in context of JEP 493 [v4]

On Mon, 7 Apr 2025 13:35:57 GMT, Severin Gehwolf wrote: >> For JEP 493-enabled builds there are no JMODs. Certain files come from the >> installed JDK image when a user creates a custom run-time from it. This is >> problematic for example for files that often come from a different package >> (

Re: RFR: 8353267: jmod create finds the wrong set of packages when class file are in non-package location

On Mon, 7 Apr 2025 15:08:56 GMT, Roger Riggs wrote: >> `jmod create` maps the contents of the module to a set of packages. This >> mapping derives illegal package names when class resources are located in >> non-package locations, e.g. in the META-INF tree. `jlink` also has an issue >> in this

Re: RFR: 8352971: Increase maximum number of hold counts for ReentrantReadWriteLock [v2]

On Mon, 7 Apr 2025 13:55:27 GMT, Viktor Klang wrote: >> I'm breaking this change out as a separate improvement, since it will not be >> generally possible to adjust these limits on the j.u.c primitives since they >> might already use a backing `long` to pack in information which needs to be >>

Re: RFR: 8353659: SubmissionPublisherTest::testCap1Submit times out

On Sun, 6 Apr 2025 12:36:43 GMT, Viktor Klang wrote: > This PR reverts the deactivation changes of the updates to FJP introduced in > JDK-8319447. Marked as reviewed by alanb (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/24473#pullrequestreview-2746919024

Re: RFR: 8353698: Output of Simple Web Server is garbled if the console's encoding is not UTF-8 [v3]

On Mon, 7 Apr 2025 09:25:08 GMT, Daniel Fuchs wrote: >> src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/JWebServer.java >> line 66: >> >>> 64: setMaxConnectionsIfNotSet(); >>> 65: >>> 66: int ec = SimpleFileServerImpl.start(new PrintWriter(System.out, >>> true

Re: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods

On Sat, 5 Apr 2025 02:30:33 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/IO.java line 147: >> >>> 145: } catch (IOException ioe) { >>> 146: throw new IOError(ioe); >>> 147: } >> >> Was `UncheckedIOException` considered? It might be better for begin

Re: RFR: 8344706: Compiler Implementation of Compact Source Files and Instance Main Methods

On Fri, 4 Apr 2025 07:20:23 GMT, Jan Lahoda wrote: > This is a PR that implements JEP: Compact Source Files and Instance Main > Methods. Changes include: > - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` > to implement the methods (thanks to @stuart-marks) > - `jav

Re: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v10]

On Mon, 7 Apr 2025 09:02:04 GMT, Jaikiran Pai wrote: >> Can I please get a review of this doc-only change which proposes to improve >> the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, >> `InflaterInputStream` and `InflaterOutputStream` classes? >> >> As noted in https://

Re: RFR: 8353641: Deprecate core library permission classes for removal [v6]

On Fri, 4 Apr 2025 19:22:46 GMT, Roger Riggs wrote: >> Now that the Security Manager is permanently disabled, the following >> permission classes in the core libraries area can be deprecated for removal >> as they are no longer useful: FilePermission, LinkPermission, >> LoggingPermission, Prop

Re: RFR: 8353641: Deprecate core library permission classes for removal [v6]

On Fri, 4 Apr 2025 19:22:46 GMT, Roger Riggs wrote: >> Now that the Security Manager is permanently disabled, the following >> permission classes in the core libraries area can be deprecated for removal >> as they are no longer useful: FilePermission, LinkPermission, >> LoggingPermission, Prop

Re: RFR: 8353641: Deprecate core library permission classes for removal [v6]

On Fri, 4 Apr 2025 19:22:46 GMT, Roger Riggs wrote: >> Now that the Security Manager is permanently disabled, the following >> permission classes in the core libraries area can be deprecated for removal >> as they are no longer useful: FilePermission, LinkPermission, >> LoggingPermission, Prop

Re: RFR: 8353698: Output of Simple Web Server is garbled if the console's encoding is not UTF-8 [v3]

On Fri, 4 Apr 2025 09:13:30 GMT, Daishi Tabata wrote: >> The output `jwebserver` and `java -m jdk.httpserver` uses UTF-8 encoding. >> Therefore, if the console encoding is not set to UTF-8 (for example, MS932 >> on Japanese Windows), garbled characters may appear.  >> Since System.out knows the

Re: RFR: 8352489: Relax jspawnhelper version checks to informative

On Thu, 20 Mar 2025 09:52:02 GMT, Aleksey Shipilev wrote: > See the bug for rationale. > > This goal for this improvement is to be easily backportable, so we can catch > up with update releases. As such, it does a few borderline-trivial changes, > and _does not_ change the jspawnhelper protoc

Re: RFR: 8352044: Add --with-import-jvms to configure

On Wed, 19 Mar 2025 12:45:23 GMT, Erik Joelsson wrote: > Just to make sure I'm understanding you correctly. Are you proposing that > instead of building a single JDK distribution with multiple JVMs, they would > build a separate JDK for each alternative JVM configuration and publish > java.bas

Re: RFR: 8352906: stdout/err.encoding on Windows set by incorrect Win32 call [v3]

On Thu, 27 Mar 2025 16:03:08 GMT, Naoto Sato wrote: >> Those system property values on Windows were derived from Windows' >> `GetConsoleCP()` call, but they should have been taken from >> `GetConsoleOutputCP()`. Replacing the incorrect call with the correct one >> won't change any behavior, as

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

On 31/03/2025 16:51, Engebretson, John wrote:   Alan – is this what you have in mind: ByteArrayOutputStream.getInstance() // returns existing class ByteArrayOutputStream.getUnsynchronizedInstance() // returns subclass of BAOS that overrides the synchronization ByteArrayOutputStream.getInsta

Re: RFR: 8352971: Increase maximum number of hold counts for ReentrantReadWriteLock

On Thu, 27 Mar 2025 11:30:11 GMT, Alan Bateman wrote: >> I'm breaking this change out as a separate improvement, since it will not be >> generally possible to adjust these limits on the j.u.c primitives since they >> might already use a backing `long` to pack in inform

RFR: 8353267: jmod create finds the wrong set of packages when class file are in non-package location

`jmod create` maps the contents of the module to a set of packages. This mapping derives illegal package names when class resources are located in non-package locations, e.g. in the META-INF tree. `jlink` also has an issue in this area and doesn't correctly determine if a resource is in a named

Re: RFR: 8352971: Increase maximum number of hold counts for ReentrantReadWriteLock

On Wed, 26 Mar 2025 16:19:16 GMT, Viktor Klang wrote: > I'm breaking this change out as a separate improvement, since it will not be > generally possible to adjust these limits on the j.u.c primitives since they > might already use a backing `long` to pack in information which needs to be > up

Re: RFR: 8353322: Specification of ChoiceFormat#parse(String, ParsePosition) is inadequate [v3]

On Wed, 2 Apr 2025 19:43:29 GMT, Justin Lu wrote: >> src/java.base/share/classes/java/text/ChoiceFormat.java line 562: >> >>> 560: /** >>> 561: * Parses a {@code Number} from the input text, the subtype of >>> which is always >>> 562: * {@code Double}. The value returned is the {@

Re: RFR: 8353185: Introduce the concept of upgradeable files in context of JEP 493

On Thu, 3 Apr 2025 06:12:35 GMT, Bernd wrote: > What about changes to conf files, especially Java.security (for hardening TLS > settings) - or at least pointing to a include? The opposite is where weaker or insecure algorithms are enabled, wouldn't want that copied by jlink into another run-ti

Re: RFR: 8353185: Introduce the concept of upgradeable files in context of JEP 493

On Thu, 3 Apr 2025 10:25:28 GMT, Severin Gehwolf wrote: > I'm not entirely sure what you are suggesting. Is it keeping a list of > "upgradeable" files in a properties file. Files listed in that properties > file aren't checked for hash sums (i.e. even if it's not modified)? That is, > the expl

Re: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v8]

On Thu, 3 Apr 2025 11:40:23 GMT, Jaikiran Pai wrote: >> Can I please get a review of this doc-only change which proposes to improve >> the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, >> `InflaterInputStream` and `InflaterOutputStream` classes? >> >> As noted in https://

Re: RFR: 8353185: Introduce the concept of upgradeable files in context of JEP 493

On Wed, 2 Apr 2025 18:39:57 GMT, Severin Gehwolf wrote: > For JEP 493-enabled builds there are no JMODs. Certain files come from the > installed JDK image when a user creates a custom run-time from it. This is > problematic for example for files that often come from a different package > (e.g.

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

On 02/04/2025 19:04, Engebretson, John wrote:   Apologies, human error – here’s the message I intended:   Thank you!  I’ve updated the PR accordingly and summarized the benchmarks in the description.  Here’s the short version: * For small payloads, unsynchronized and optimized versions are

Re: RFR: 8353322: Specification of ChoiceFormat#parse(String, ParsePosition) is inadequate [v3]

On Wed, 2 Apr 2025 19:43:29 GMT, Justin Lu wrote: >> src/java.base/share/classes/java/text/ChoiceFormat.java line 562: >> >>> 560: /** >>> 561: * Parses a {@code Number} from the input text, the subtype of >>> which is always >>> 562: * {@code Double}. The value returned is the {@

Re: RFD: Query param discrepancy in unix/windows file Handler:openConnection

On 01/04/2025 20:09, Eirik Bjørsnøs wrote: : Looking at the Windows implementation of sun.net.protocol.www.file.Handler, it indeed uses URL::getFile when constructing the file path, while the unix implementation uses URL::getPath. As a general point, neither method is correct when conver

Re: RFR: 8353322: Specification of ChoiceFormat#parse(String, ParsePosition) is inadequate [v3]

On Tue, 1 Apr 2025 20:32:45 GMT, Justin Lu wrote: >> Please review this PR which specifies the `ChoiceFormat#parse(String, >> ParsePosition)` method. A corresponding CSR is filed. The current >> specification is simply "Parses a Number from the input text" which does not >> indicate how the va

Re: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33]

On Wed, 2 Apr 2025 13:22:44 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with one additional > commit since the last revision: > > Add info that Map#values and Map#entrySet are stable src/java

Re: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33]

On Wed, 2 Apr 2025 13:22:44 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with one additional > commit since the last revision: > > Add info that Map#values and Map#entrySet are stable src/java

Re: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v25]

On Wed, 2 Apr 2025 12:56:23 GMT, Per Minborg wrote: >> Same in other factories... > > We had that originally and then I got the comment to move them to the > factories so I am happy to do either as soon as we agree on the best way to > do it. I'm also puzzled as to why this is here as it becom

Re: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v33]

On Wed, 2 Apr 2025 13:22:44 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with one additional > commit since the last revision: > > Add info that Map#values and Map#entrySet are stable src/java

Re: RFR: 8353322: Specification of ChoiceFormat#parse(String, ParsePosition) is inadequate [v3]

On Tue, 1 Apr 2025 20:32:45 GMT, Justin Lu wrote: >> Please review this PR which specifies the `ChoiceFormat#parse(String, >> ParsePosition)` method. A corresponding CSR is filed. The current >> specification is simply "Parses a Number from the input text" which does not >> indicate how the va

Re: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups() can lock up target VM [v7]

On Tue, 1 Apr 2025 20:00:22 GMT, Chris Plummer wrote: >> Calling ThreadGroupReference.groups() from an event handler can cause a >> deadlock. Details in first comment. Tested with :jdk_lang on all supported >> platforms and tier1, tier2, tier3, and tier5 svc testing. > > Chris Plummer has updat

Re: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups() can lock up target VM [v7]

On Tue, 1 Apr 2025 20:00:22 GMT, Chris Plummer wrote: >> Calling ThreadGroupReference.groups() from an event handler can cause a >> deadlock. Details in first comment. Tested with :jdk_lang on all supported >> platforms and tier1, tier2, tier3, and tier5 svc testing. > > Chris Plummer has updat

Re: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v7]

On Tue, 1 Apr 2025 07:22:45 GMT, Jaikiran Pai wrote: >> Can I please get a review of this doc-only change which proposes to improve >> the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, >> `InflaterInputStream` and `InflaterOutputStream` classes? >> >> As noted in https://

Re: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v6]

On Tue, 1 Apr 2025 14:50:01 GMT, Chen Liang wrote: >> It's hard for me to guess what prompted that question, but I'll take a guess >> - are you asking this question to decide whether we should reword the >> pre-existing javadoc on these constructors to explicitly state that a new >> decompress

Re: RFR: 8352689: Allow for hash sum overrides when linking from the run-time image [v2]

On Wed, 26 Mar 2025 14:50:11 GMT, Alan Bateman wrote: >>> > The cacerts issue mentioned in the JBS issue relates to an RPM >>> > installation of the JDK where the cacerts file is a symlink to the distro >>> > provided one. So I think that's &

Re: RFR: 8353449: [BACKOUT] One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683

On Tue, 1 Apr 2025 12:41:48 GMT, David Holmes wrote: > Revert "8353272: One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683" > > This reverts commit cef5610b5d4f7c5c2ceda46995ef3a0d961294e5. > > This causes failures building the static libs on Windows and macOS. > > Thanks Marked as r

Integrated: 8353331: Test ForkJoinPool20Test::testFixedDelaySequence is failing

On Tue, 1 Apr 2025 10:56:25 GMT, Alan Bateman wrote: > ForkJoinPool20Test::testFixedDelaySequence is failing intermittently. The > assert that checks that the periodically tasks only executes 8 times is > removed, it may run more than this before it cancelled. This pull request has

RFR: 8353331: Test ForkJoinPool20Test::testFixedDelaySequence is failing

ForkJoinPool20Test::testFixedDelaySequence is failing intermittently. The assert that checks that the periodically tasks only executes 8 times is removed, it may run more than this before it cancelled. - Commit messages: - Drop assert Changes: https://git.openjdk.org/jdk/pull/2435

Re: On passing --date to jrt-fs jar at build time

On 01/04/2025 08:52, Galder Zamarreno wrote: I'm not sure what "test harness" and "test jar" means here but just to say that jrt-fs.jar is in the JDK run-time. ^ Are you sure? The default make target, `exploded-image`, doesn't build the jrt-fs.jar. Aside from `test`, `images` does bu

Re: RFR: 8351435: Change the default Console implementation back to the built-in one in `java.base` module [v2]

On Wed, 12 Mar 2025 17:02:01 GMT, Naoto Sato wrote: >> JDK has been using JLine based Console implementation, in JDK20 as opt-in, >> then in JDK22 as the default. While it has been providing rich functionality >> for Console, it is increasingly difficult to maintain as a Console >> implementat

Re: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v6]

On Thu, 27 Mar 2025 07:23:07 GMT, Jaikiran Pai wrote: >> Can I please get a review of this doc-only change which proposes to improve >> the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`, >> `InflaterInputStream` and `InflaterOutputStream` classes? >> >> As noted in https:/

Re: RFD: FTP fallback of the 'file:' URL scheme

On 29/03/2025 16:48, Eirik Bjørsnøs wrote: Hi, The long-standing FTP fallback feature supported by the 'file:' URL scheme handler seems dubious to me I recall digging into this a long time ago and concluded that it's was an interpretation of RFC 1738 section 3.10. I can't imagine anything r

Re: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups() can lock up target VM [v6]

On Fri, 28 Mar 2025 21:02:21 GMT, Chris Plummer wrote: >> Calling ThreadGroupReference.groups() from an event handler can cause a >> deadlock. Details in first comment. Tested with :jdk_lang on all supported >> platforms and tier1, tier2, tier3, and tier5 svc testing. > > Chris Plummer has upda

Re: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups() can lock up target VM [v6]

On Fri, 28 Mar 2025 21:02:21 GMT, Chris Plummer wrote: >> Calling ThreadGroupReference.groups() from an event handler can cause a >> deadlock. Details in first comment. Tested with :jdk_lang on all supported >> platforms and tier1, tier2, tier3, and tier5 svc testing. > > Chris Plummer has upda

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

On 28/03/2025 13:05, Engebretson, John wrote: Hi all!  This message is to discuss the proposal for a public class that is faster/cheaper than ByteArrayOutputStream.  Details are on the ticket [1] so I will only summarize here: - ByteArrayOutputStream is slower than the provided alternative,

Re: On passing --date to jrt-fs jar at build time

On 28/03/2025 09:25, Galder Zamarreno wrote: : However, @Thomas Fitzsimmons  had a very good point to make: > I also wonder why the test harness is passing |--date $SOURCE_DATE_EPOCH|, since the test jars are not distributed, not sure why they'd need to be reprodu

Re: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe [v2]

On Fri, 21 Feb 2025 07:10:16 GMT, Alan Bateman wrote: >> Nicole Xu has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - 8349944: [JMH] sun.misc.UnsafeOps cannot access class >> jdk.internal.misc.Unsafe

Re: RFR: 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance

On Sun, 23 Mar 2025 12:38:04 GMT, Jason Zaugg wrote: > 8352642: Set zipinfo-time=false when constructing zipfs FileSystem in > com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better > performance > I agree that passing zipinfo-time to an unknown provider is likely quite safe. R

Re: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups() can lock up target VM [v4]

On Wed, 26 Mar 2025 20:50:36 GMT, Chris Plummer wrote: >> Calling ThreadGroupReference.groups() from an event handler can cause a >> deadlock. Details in first comment. Tested with :jdk_lang on all supported >> platforms and tier1, tier2, tier3, and tier5 svc testing. > > Chris Plummer has upda

  1   2   3   4   5   6   7   8   9   10   >