RFR: 8357179: Deprecate VFORK launch mechanism from Process implementation (linux)

For the ratio behind this please see the companion CSR: https://bugs.openjdk.org/browse/JDK-8357180. We plan to deprecate this in JDK 25 and to remove it in JDK 26. This patch just writes a deprecation message to stderr: 08:46:38 thomas@starfish java -Djdk.lang.Process.launchMechanism=VFORK S

Re: ProcessImpl: Can we obsolete the vfork mode?

This is the deprecation issue: https://bugs.openjdk.org/browse/JDK-8357179 Deprecation patch PR: https://github.com/openjdk/jdk/pull/25282 Deprecation CSR: https://bugs.openjdk.org/browse/JDK-8357180 Deprecation Release Note: https://bugs.openjdk.org/browse/JDK-8357181 Cheers, Thomas On Sat, May

Re: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22]

On Fri, 16 May 2025 20:00:53 GMT, Roger Riggs wrote: >> This API is concerned with the "what" and not so much the "how." > > The purpose of Reader and subclasses is to normalize characters in various > forms (char arrays, byte streams, char buffers, etc) into a coherent stream > of characters a

Re: ProcessImpl: Can we obsolete the vfork mode?

Side note, I did not find any tests for the VFORK mode. Even the FORK mode seems not that well covered ( we only seem to run java/lang/ProcessBuilder/Basic.java in FORK mode) On Fri, May 16, 2025 at 6:59 PM Thomas Stüfe wrote: > I am fine with waiting past 25, though the continued existence of t

Re: Towards a JSON API for the JDK

I fail to see a fundamental difference in level (high vs. low) - we should consider extensibility, ergonomics, and how people are likely to use the API. "It gets in the way of laziness" is a valid reason to have JsonObject not be a Map (though I still want to interrogate it), "the idea is to use d

RFR: 8356985: Use "stdin.encoding" in Console's read*() methods

`java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cas

RFR: 8357178: Simplify Class::componentType

`isArray` and null return is now redundant when `componentType` is changed to an explicit field. - Commit messages: - 8357178: Simplify Class::componentType Changes: https://git.openjdk.org/jdk/pull/25280/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25280&range=00 Iss

Re: RFR: 8351230: Collections.synchronizedList returns a list that is not thread-safe [v3]

On Sat, 17 May 2025 01:25:14 GMT, Stuart Marks wrote: >> Collections.synchronizedList() returns a List implementation that doesn't do >> proper locking. This PR does the following on the synchronized wrapper: >> >> - overrides and adds locking to SequencedCollection methods; >> - performs insta

Re: RFR: 8345431: Improve jar --validate to detect duplicate or invalid entries [v9]

> This PR check the jar file to ensure entries are consistent from the central > directory and local file header. Also check there is no duplicate entry names > that could override the desired content by accident. Henry Jen has updated the pull request incrementally with one additional commit s

Re: RFR: 8351230: Collections.synchronizedList returns a list that is not thread-safe [v3]

> Collections.synchronizedList() returns a List implementation that doesn't do > proper locking. This PR does the following on the synchronized wrapper: > > - overrides and adds locking to SequencedCollection methods; > - performs instance management of reversed synchronized views; > - adds test

Re: RFR: 8351230: Collections.synchronizedList returns a list that is not thread-safe [v2]

On Thu, 15 May 2025 12:17:14 GMT, Per Minborg wrote: >> Stuart Marks has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Reversed view of SynchronizedRandomAccessList should also be RandomAccess. >> Add tests to ensure RandomAccess is pres

Re: RFR: 8351230: Collections.synchronizedList returns a list that is not thread-safe [v2]

On Fri, 16 May 2025 09:24:13 GMT, Jaikiran Pai wrote: >> Stuart Marks has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Reversed view of SynchronizedRandomAccessList should also be RandomAccess. >> Add tests to ensure RandomAccess is pre

Re: RFR: 8333664: Decouple command line parsing and package building in jpackage [v5]

On Fri, 16 May 2025 23:43:48 GMT, Alexey Semenyuk wrote: >> Refactor jpackage to separate the configuration and execution phases. >> At the configuration phase, jpackage parses command-line arguments and >> validates them. >> At the execution phase, jpackage builds a bundle based on data collect

Withdrawn: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops

On Wed, 14 May 2025 19:37:37 GMT, Archie Cobbs wrote: > Please review this small performance tweak `ArrayDeque`. > > `ArrayDeque` has an invariant in which any unused elements in the array must > be null. In a couple of places, the code is setting contiguous ranges of > elements to null using

Re: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops [v3]

On Thu, 15 May 2025 21:04:40 GMT, Archie Cobbs wrote: >> Please review this small performance tweak `ArrayDeque`. >> >> `ArrayDeque` has an invariant in which any unused elements in the array must >> be null. In a couple of places, the code is setting contiguous ranges of >> elements to null u

Re: RFR: 8333664: Decouple command line parsing and package building in jpackage [v4]

On Sat, 10 May 2025 19:02:45 GMT, Alexey Semenyuk wrote: >> Refactor jpackage to separate the configuration and execution phases. >> At the configuration phase, jpackage parses command-line arguments and >> validates them. >> At the execution phase, jpackage builds a bundle based on data collect

Re: RFR: 8333664: Decouple command line parsing and package building in jpackage [v5]

> Refactor jpackage to separate the configuration and execution phases. > At the configuration phase, jpackage parses command-line arguments and > validates them. > At the execution phase, jpackage builds a bundle based on data collected at > the configuration phase. > > There was no clear separ

回复：Towards a JSON API for the JDK

As the author of a popular json library (fastjson/fastjson2), I think the current design is not good, not easy to use, and the performance is not good. The JsonNull/JsonNumber/JsonString/JsonValue here should not be designed like this, which will cause trouble to users and affect performance. For

Re: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6]

On Wed, 30 Apr 2025 22:26:30 GMT, Chen Liang wrote: >> In offline discussion, we noted that the documentation on this annotation >> does not recommend minimizing the intrinsified section and moving whatever >> can be done in Java to Java; thus I prepared this documentation update, to >> shrink

Re: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22]

On Thu, 15 May 2025 20:34:13 GMT, Brian Burkhalter wrote: >> @stuart-marks Sorry, didn't want to pull you in here, that's why I said, I >> am just *paraphrasing*. >> >> That is correct, it is a different case, but the *final effect* for the >> caller is the same: If he needs to now whether a c

Withdrawn: 8351842: Windows specific issues in combination of JEP 493 and --with-external-symbols-in-bundles=public

On Fri, 14 Mar 2025 12:29:22 GMT, Christoph Langer wrote: > Alternative approach to #24012 > > This keeps the current handling of *.pdb vs *.stripped.pdb which allows > debugging at the cost of a little hack in jlink. Maybe the code in jlink can > be improved, e.g. make it more conditional. >

RFR: 8357062: Update Public Suffix List to 823beb1

This is a routine update to synchronize with the [Mozilla Public Suffix List](https://github.com/publicsuffix/list) for JDK 25, matching commit 823beb1 from 2025-05-12. The test has been updated to reflect corresponding changes. - Commit messages: - the fix Changes: https://git.o

Re: RFR: 8333664: Decouple command line parsing and package building in jpackage [v4]

On Tue, 13 May 2025 01:55:19 GMT, Alexander Matveev wrote: >> Alexey Semenyuk has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 512 commits: >> >> - Add ConfigFilesStasher that allows to save contents of jpackage build >> directo

Re: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v6]

On Wed, 30 Apr 2025 22:26:30 GMT, Chen Liang wrote: >> In offline discussion, we noted that the documentation on this annotation >> does not recommend minimizing the intrinsified section and moving whatever >> can be done in Java to Java; thus I prepared this documentation update, to >> shrink

Re: RFR: 8333664: Decouple command line parsing and package building in jpackage [v4]

On Sat, 10 May 2025 19:02:45 GMT, Alexey Semenyuk wrote: >> Refactor jpackage to separate the configuration and execution phases. >> At the configuration phase, jpackage parses command-line arguments and >> validates them. >> At the execution phase, jpackage builds a bundle based on data collect

Re: RFR: 8345431: Detect duplicate entries in jar files with jar --validate [v8]

On Thu, 15 May 2025 21:57:17 GMT, Henry Jen wrote: >> This PR check the jar file to ensure entries are consistent from the central >> directory and local file header. Also check there is no duplicate entry >> names that could override the desired content by accident. > > Henry Jen has updated t

Re: Towards a JSON API for the JDK

> From: "Brian Goetz" > To: "Remi Forax" > Cc: "Paul Sandoz" , "core-libs-dev" > > Sent: Friday, May 16, 2025 7:46:09 PM > Subject: Re: Towards a JSON API for the JDK > If you read the implementation, you'll see that significant laziness is indeed > possible for JsonObject and JsonArray, even w

Re: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22]

On Fri, 16 May 2025 18:21:10 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/io/Reader.java line 478: >> >>> 476: * >>> 477: * If an I/O error occurs reading from the stream, then it >>> 478: * may do so after some, but not all, characters have been read. >> >>

Re: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22]

On Fri, 16 May 2025 07:57:01 GMT, Jaikiran Pai wrote: > I read this sentence a couple of times [...] Please see [a86610d](https://github.com/openjdk/jdk/pull/24728/commits/a86610d06169445a5c4b81a0c60527130a45e045). > I suspect that sentence was motivated from similar existing text in > `Files

Re: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v23]

> Implement the requested methods and add a test thereof. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8354724: Improve verbiage about I/O errors - Changes: - all: https://git.openjdk.org/jdk/pull/24728/files

Re: Towards a JSON API for the JDK

- Original Message - > From: "naoto sato" > To: "Remi Forax" , "Paul Sandoz" > Cc: "core-libs-dev" > Sent: Friday, May 16, 2025 6:35:50 PM > Subject: Re: Towards a JSON API for the JDK > Hi Rémi, > > On 5/15/25 2:27 PM, Remi Forax wrote: >> Hi Paul, >> yes, not having a simple JSON API

Re: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22]

On Fri, 16 May 2025 18:13:45 GMT, Roger Riggs wrote: > Is this better? I think it is clearer. - PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2093501372

Re: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22]

On Wed, 14 May 2025 18:16:22 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter has updated the pull request incrementally with one > additional commit since the last revision: > > 8354724: Replace getChars in previous commit with subS

Integrated: 8357075: Remove leftover COMPAT locale data tests

On Thu, 15 May 2025 19:31:45 GMT, Naoto Sato wrote: > Removing now-defunct COMPAT locale provider tests. This pull request has now been integrated. Changeset: 3dd34517 Author:Naoto Sato URL: https://git.openjdk.org/jdk/commit/3dd34517000e4ce1a21619922c62c025f98aad44 Stats: 8496

Re: RFR: 8357075: Remove leftover COMPAT locale data tests [v2]

On Thu, 15 May 2025 20:53:10 GMT, Naoto Sato wrote: >> Removing now-defunct COMPAT locale provider tests. > > Naoto Sato has updated the pull request incrementally with three additional > commits since the last revision: > > - Update test/jdk/sun/text/resources/LocaleDataTest.java > >C

Re: Towards a JSON API for the JDK

If you read the implementation, you'll see that significant laziness is indeed possible for JsonObject and JsonArray, even while doing eager validation.  (Of course, one can shift the balance to achieve various other tradeoffs.) On 5/16/2025 10:35 AM, fo...@univ-mlv.fr wrote: - Original M

Re: Towards a JSON API for the JDK

Thanks for the sneak peek. I'd suggest adding a security section to the JEP, when the time comes. Most input to this JSON parsing API will probably be untrusted, and this is an area where "last mover advantage" can be helpful. As a user, the progression I've seen in other JSON parsers was a first

Re: RFR: 8355954: File.delete removes read-only files (win) [v6]

> This change proposes to modify `java.io.File.delete()` so that regular files > on Windows will not be deleted by default if their read-only attribute is > set. A boolean-valued system compatibility property > `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if > desired.

Re: RFR: 8357075: Remove leftover COMPAT locale data tests [v2]

On Thu, 15 May 2025 20:53:10 GMT, Naoto Sato wrote: >> Removing now-defunct COMPAT locale provider tests. > > Naoto Sato has updated the pull request incrementally with three additional > commits since the last revision: > > - Update test/jdk/sun/text/resources/LocaleDataTest.java > >C

Re: Towards a JSON API for the JDK

Since the parser is specified to be lazy, the backing store needs to be immutable. On 2025-05-16 18:52, Markus KARG wrote: When instead allowing the general interface CharSequence, *any* kind of text source can be parsed, for example, an off-heap located direct CharBuffer, without the need to

Re: RFR: 8355954: File.delete removes read-only files (win) [v4]

On Fri, 16 May 2025 06:28:14 GMT, Brian Burkhalter wrote: >> test/jdk/java/io/File/DeleteReadOnly.java line 47: >> >>> 45: >>> 46: private static final File DIR = new File(".", "dir"); >>> 47: private static final File FILE = new File(DIR, "file"); >> >> If one of the tests fails then

Re: ProcessImpl: Can we obsolete the vfork mode?

I am fine with waiting past 25, though the continued existence of this mode makes me apprehensive. Back at SAP I have seen real customer issues from these kind of problems, and we only catched those out of accident. A separate deprecation for JDK 25 may be a good first step (a warning, but continu

Re: Towards a JSON API for the JDK

As the API intentionally uses interfaces to open the ability to optimize the implementation, it would be also just straightforward to not limit the text source to the explicit class String. When instead allowing the general interface CharSequence, *any* kind of text source can be parsed, for ex

Re: RFR: 8357063: Document preconditions for DecimalDigits methods [v4]

On Fri, 16 May 2025 16:10:29 GMT, Shaojin Wen wrote: >> Similar to PR #24982 >> Document preconditions on certain DecimalDigits methods that use operations >> either unsafe and/or without range checks. > > Shaojin Wen has updated the pull request incrementally with one additional > commit sinc

Re: RFR: 8357075: Remove leftover COMPAT locale data tests [v2]

On Thu, 15 May 2025 20:53:10 GMT, Naoto Sato wrote: >> Removing now-defunct COMPAT locale provider tests. > > Naoto Sato has updated the pull request incrementally with three additional > commits since the last revision: > > - Update test/jdk/sun/text/resources/LocaleDataTest.java > >C

Re: Towards a JSON API for the JDK

Hi Rémi, On 5/15/25 2:27 PM, Remi Forax wrote: Hi Paul, yes, not having a simple JSON API in Java is an issue for beginners. It's not clear to me why JsonArray (for example) has to be an interface instead of a record ? I understand why Json.parse() only works on String and char[] but the API

Re: RFR: 8357052: java/io/File/GetXSpace.java prints wrong values in exception

On Thu, 15 May 2025 13:49:14 GMT, Arno Zeller wrote: > When the test java/io/File/GetXSpace.java fails, because the usable space is > greater than the free space, the values in the exception are not the correct > ones. Looks correct. - Marked as reviewed by bpb (Reviewer). PR Re

Re: ProcessImpl: Can we obsolete the vfork mode?

I concur that this work is better down early in JDK 26. Thanks, -Joe On 5/16/2025 12:26 AM, Thomas Stüfe wrote: Okay, moved the release version to 26. Could one of you (you or @Roger Riggs ) review the CSR if you have the cycles to spare? https://bugs.openjd

Re: RFR: 8355954: File.delete removes read-only files (win) [v5]

> This change proposes to modify `java.io.File.delete()` so that regular files > on Windows will not be deleted by default if their read-only attribute is > set. A boolean-valued system compatibility property > `jdk.io.File.deleteReadOnly` is defined to reinstate legacy behavior if > desired.

Re: RFR: 8357063: Document preconditions for DecimalDigits methods [v4]

> Similar to PR #24982 > Document preconditions on certain DecimalDigits methods that use operations > either unsafe and/or without range checks. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: warning - Changes: - al

Re: RFR: 8357063: Document preconditions for DecimalDigits methods [v3]

> Similar to PR #24982 > Document preconditions on certain DecimalDigits methods that use operations > either unsafe and/or without range checks. Shaojin Wen has updated the pull request incrementally with seven additional commits since the last revision: - Update src/java.base/share/classes/

Re: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19]

On Thu, 15 May 2025 22:07:05 GMT, Brian Burkhalter wrote: >> It is **impossible** to "invest some lines" to solve this in JAX-RS, and >> JAX-RS as a standard technology on tens of thousands of servers. Enforcing >> `String` prevents these useful optimizations, but brings *no actual >> benefit*

Re: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4]

On Fri, 16 May 2025 05:34:09 GMT, Alan Bateman wrote: >> David Beaumont has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Changes based on review feedback. > > src/jdk.zipfs/share/classes/module-info.java line 299: > >> 297: *

Re: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4]

On Fri, 16 May 2025 14:30:38 GMT, Jaikiran Pai wrote: >> David Beaumont has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Changes based on review feedback. > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 230: > >> 22

Re: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4]

On Mon, 12 May 2025 09:49:12 GMT, David Beaumont wrote: >> David Beaumont has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Changes based on review feedback. > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 221: > >>

Re: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4]

On Thu, 15 May 2025 18:27:35 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite >> values, and ensures that the requested mode is consistent with what's >> returned. >> >> This involved a l

Re: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4]

On Thu, 15 May 2025 18:27:35 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite >> values, and ensures that the requested mode is consistent with what's >> returned. >> >> This involved a l

Re: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4]

On Thu, 15 May 2025 18:27:35 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite >> values, and ensures that the requested mode is consistent with what's >> returned. >> >> This involved a l

Re: Towards a JSON API for the JDK

- Original Message - > From: "Brian Goetz" > To: "Remi Forax" , "Paul Sandoz" > Cc: "core-libs-dev" > Sent: Friday, May 16, 2025 2:53:18 PM > Subject: Re: Towards a JSON API for the JDK > On 5/15/2025 5:27 PM, Remi Forax wrote: >> It's not clear to me why JsonArray (for example) has to

Re: RFR: 8350880: (zipfs) Add support for read-only zip file systems [v4]

On Thu, 15 May 2025 18:27:35 GMT, David Beaumont wrote: >> Adding read-only support to ZipFileSystem. >> >> The new `accessMode` environment property allows for readOnly and readWrite >> values, and ensures that the requested mode is consistent with what's >> returned. >> >> This involved a l

Re: Towards a JSON API for the JDK

Ahh, as expected some great thoughts have gone into this. :-) Allowing the ignore of comments when parsing is not "inventing a new format", IMO. More so because the RFC allows it (section 9) and because it would be strictly opt-in. So the parser can still be said to be strictly RFC-8259 while opt

Re: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v5]

On Fri, 9 May 2025 14:39:53 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the >> HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the >> HTTP Client API](http

Re: RFR: 8357063: Document preconditions for DecimalDigits methods [v2]

On Fri, 16 May 2025 09:45:43 GMT, Shaojin Wen wrote: >> Similar to PR #24982 >> Document preconditions on certain DecimalDigits methods that use operations >> either unsafe and/or without range checks. > > Shaojin Wen has updated the pull request incrementally with two additional > commits sin

Re: Towards a JSON API for the JDK

I would like to add JSON comments from my perspective. I had a requirement of working with JSON in java multiple times during working on the university assignments recently. Since those are small, often one-time-open projects, I did not want (or, often, it was forbidden by assignment) to pull in w

Integrated: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive

On Tue, 25 Mar 2025 11:08:24 GMT, Timofei Pushkin wrote: > If a base class is package-private then its subclasses should have the same > package name and defining class loader, otherwise `IllegalAccessError` is > thrown when linking a subclass. Currently when dumping a static archive > separat

Re: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v12]

On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same >> package name and defining class loader, otherwise `IllegalAccessError` is >> thrown when linking a subclass. Currently when dumping a static archive >> sep

Re: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v6]

On Thu, 15 May 2025 22:43:54 GMT, Shaojin Wen wrote: >> fabioromano1 has updated the pull request incrementally with one additional >> commit since the last revision: >> >> make magBitLength() an instance method > > src/java.base/share/classes/java/math/BigInteger.java line 3860: > >> 3858:

Re: RFR: 8357063: Document preconditions for DecimalDigits methods [v2]

On Fri, 16 May 2025 09:45:43 GMT, Shaojin Wen wrote: >> Similar to PR #24982 >> Document preconditions on certain DecimalDigits methods that use operations >> either unsafe and/or without range checks. > > Shaojin Wen has updated the pull request incrementally with two additional > commits sin

Re: Towards a JSON API for the JDK

At first, we were hopeful that we could jump right to JSON5, which appears at first glance to be a strictly lexical, more permissive grammar for JSON (supporting comments, trailing commas, more flexible quoting, white space, etc.)  If that were actually true, this would have been a slam dunk, s

Re: Towards a JSON API for the JDK

Great work. I feel the elephant in the room needs to addressed: JSON comments. I haven't tested the proposed lib but I cannot see it mentioned so I'm assuming that comments are not supported. For better or worse, the use of jsonc (JSON with comments) is everywhere in some ecosystems. Unsurprisi

Re: Towards a JSON API for the JDK

On 5/15/2025 5:27 PM, Remi Forax wrote: It's not clear to me why JsonArray (for example) has to be an interface instead of a record ? Oh, you know the answer to this.  A record limits us to a single implementation with a rigid representation.  Behind an interface, we can hide lazy parsing

Integrated: 8353888: Implement JEP 510: Key Derivation Function API

On Tue, 8 Apr 2025 18:14:53 GMT, Weijun Wang wrote: > Finalize the KDF API. This pull request has now been integrated. Changeset: 079fccfa Author:Weijun Wang URL: https://git.openjdk.org/jdk/commit/079fccfa9a03b890e698c52c689dea0f19f8fbee Stats: 209 lines in 18 files changed: 16

Re: Towards a JSON API for the JDK

> From: "Ethan McCue" > To: "Remi Forax" > Cc: "Paul Sandoz" , "core-libs-dev" > > Sent: Friday, May 16, 2025 1:44:52 AM > Subject: Re: Towards a JSON API for the JDK > I present for your consideration the library I made when spiraling about this > problem space a few years ago > [ https://git

Re: RFR: 8357016: Candidate main methods not computed properly [v3]

On Fri, 16 May 2025 11:54:07 GMT, Jan Lahoda wrote: >> A consider class like this: >> >> >> public class TwoMains { >> private static void main(String... args) {} >> static void main() { >> System.out.println("Should be called, but is not."); >> } >> } >> >> >> The `Method

Re: RFR: 8357016: Candidate main methods not computed properly [v3]

On Fri, 16 May 2025 11:54:07 GMT, Jan Lahoda wrote: >> A consider class like this: >> >> >> public class TwoMains { >> private static void main(String... args) {} >> static void main() { >> System.out.println("Should be called, but is not."); >> } >> } >> >> >> The `Method

Re: RFR: 8357016: Candidate main methods not computed properly [v3]

> A consider class like this: > > > public class TwoMains { > private static void main(String... args) {} > static void main() { > System.out.println("Should be called, but is not."); > } > } > > > The `MethodFinder` will do lookup for the `main(String[])` method, and it >

Re: RFR: 8357016: Candidate main methods not computed properly [v2]

On Fri, 16 May 2025 11:12:08 GMT, Jan Lahoda wrote: >> A consider class like this: >> >> >> public class TwoMains { >> private static void main(String... args) {} >> static void main() { >> System.out.println("Should be called, but is not."); >> } >> } >> >> >> The `Method

Re: RFR: 8357016: Candidate main methods not computed properly [v2]

On Fri, 16 May 2025 11:02:54 GMT, Jan Lahoda wrote: >> src/java.base/share/classes/sun/launcher/resources/launcher.properties line >> 283: >> >>> 281: make inner class static or move inner class out to separate source >>> file >>> 282: java.launcher.cls.error8=\ >>> 283: Error: abstrac

Re: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v6]

On Thu, 15 May 2025 15:37:39 GMT, fabioromano1 wrote: >> Some changes in `Biginteger`s' bit operations that increase the code >> readability and slightly optimize the execution time. > > fabioromano1 has updated the pull request incrementally with one additional > commit since the last revision

Re: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v6]

On Fri, 16 May 2025 11:43:18 GMT, fabioromano1 wrote: >> fabioromano1 has updated the pull request incrementally with one additional >> commit since the last revision: >> >> make magBitLength() an instance method > > src/java.base/share/classes/java/math/BigInteger.java line 3619: > >> 3617:

Re: RFR: 8348986: Improve coverage of enhanced exception messages [v10]

> Hi, > > Enhanced exception messages are designed to hide sensitive information such > as hostnames, IP > addresses from exception message strings, unless the enhanced mode for the > specific category > has been explicitly enabled. Enhanced exceptions were first introduced in > 8204233 in JD

Re: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v8]

> Some changes in `Biginteger`s' bit operations that increase the code > readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: An optimization - Changes: - all: https://

Re: RFR: 8357016: Candidate main methods not computed properly [v2]

On Fri, 16 May 2025 11:12:08 GMT, Jan Lahoda wrote: >> A consider class like this: >> >> >> public class TwoMains { >> private static void main(String... args) {} >> static void main() { >> System.out.println("Should be called, but is not."); >> } >> } >> >> >> The `Method

Re: RFR: 8357016: Candidate main methods not computed properly [v2]

> A consider class like this: > > > public class TwoMains { > private static void main(String... args) {} > static void main() { > System.out.println("Should be called, but is not."); > } > } > > > The `MethodFinder` will do lookup for the `main(String[])` method, and it >

Re: RFR: 8357016: Candidate main methods not computed properly [v2]

On Fri, 16 May 2025 10:07:36 GMT, Jaikiran Pai wrote: >> Jan Lahoda has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Adding tests as suggested. > > test/jdk/tools/launcher/Arrrghs.java line 607: > >> 605: //private method with pa

Re: RFR: 8357016: Candidate main methods not computed properly

On Fri, 16 May 2025 10:10:17 GMT, Jaikiran Pai wrote: >> A consider class like this: >> >> >> public class TwoMains { >> private static void main(String... args) {} >> static void main() { >> System.out.println("Should be called, but is not."); >> } >> } >> >> >> The `Meth

Re: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v5]

On Fri, 9 May 2025 14:39:53 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the >> HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the >> HTTP Client API](http

Re: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v7]

> Some changes in `Biginteger`s' bit operations that increase the code > readability and slightly optimize the execution time. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Correct bug in shiftRight - Changes: - all

RFR: 8357052: java/io/File/GetXSpace.java prints wrong values in exception

When the test java/io/File/GetXSpace.java fails, because the usable space is greater than the free space, the values in the exception are not the correct ones. - Commit messages: - Use correct variables. Changes: https://git.openjdk.org/jdk/pull/25250/files Webrev: https://webre

Re: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id contains "-J"

On Wed, 14 May 2025 14:40:41 GMT, Manuel Hässig wrote: > When passing `-J-version` to the patched javac, > `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds > to the expected version output. However, if the build id of the JDK running > this test contains the substrin

Re: RFR: 8357016: Candidate main methods not computed properly

On Thu, 15 May 2025 16:42:48 GMT, Jan Lahoda wrote: > A consider class like this: > > > public class TwoMains { > private static void main(String... args) {} > static void main() { > System.out.println("Should be called, but is not."); > } > } > > > The `MethodFinder` will

Re: RFR: 8357016: Candidate main methods not computed properly

On Thu, 15 May 2025 16:42:48 GMT, Jan Lahoda wrote: > A consider class like this: > > > public class TwoMains { > private static void main(String... args) {} > static void main() { > System.out.println("Should be called, but is not."); > } > } > > > The `MethodFinder` will

Re: RFR: 8356891: Some code simplifications for basic BigIntegers' bit operations [v6]

On Thu, 15 May 2025 22:03:40 GMT, Raffaello Giulietti wrote: > There are problems with the `test/jdk/java/math/BigInteger` tests. Can you > please crosscheck? @rgiulietti It seems there is a slowdown in the creation of large pseudoprimes, maybe due to `BitSieve` methods. - PR C

Re: RFR: 8357016: Candidate main methods not computed properly

On Thu, 15 May 2025 16:42:48 GMT, Jan Lahoda wrote: > A consider class like this: > > > public class TwoMains { > private static void main(String... args) {} > static void main() { > System.out.println("Should be called, but is not."); > } > } > > > The `MethodFinder` will

Re: RFR: 8357063: Document preconditions for DecimalDigits methods [v2]

> Similar to PR #24982 > Document preconditions on certain DecimalDigits methods that use operations > either unsafe and/or without range checks. Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: - assert - document add warnings

Re: RFR: 8351230: Collections.synchronizedList returns a list that is not thread-safe [v2]

On Mon, 5 May 2025 23:36:35 GMT, Stuart Marks wrote: >> Collections.synchronizedList() returns a List implementation that doesn't do >> proper locking. This PR does the following on the synchronized wrapper: >> >> - overrides and adds locking to SequencedCollection methods; >> - performs instan

Integrated: 8354674: AArch64: Intrinsify Unsafe::setMemory

On Fri, 9 May 2025 14:11:27 GMT, Andrew Haley wrote: > This intrinsic is generally faster than the current implementation for Panama > segment operations for all writes larger than about 8 bytes in size, > increasing to more than 2* the performance on larger memory blocks on > Graviton 2, betw

Re: RFR: 8351230: Collections.synchronizedList returns a list that is not thread-safe [v2]

On Mon, 5 May 2025 23:36:35 GMT, Stuart Marks wrote: >> Collections.synchronizedList() returns a List implementation that doesn't do >> proper locking. This PR does the following on the synchronized wrapper: >> >> - overrides and adds locking to SequencedCollection methods; >> - performs instan

Re: RFR: 8357089: Remove VFORK launch mechanism from Process implementation (linux)

On Fri, 16 May 2025 06:14:57 GMT, Thomas Stuefe wrote: > Not for JDK 25 > > See the companion CSR (https://bugs.openjdk.org/browse/JDK-8357090) for the > ratio behind this removal. > > Patch > > - removes all code handling the VFORK mode. > - removes or rewrites comments explaining use of vf

Re: RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v22]

On Wed, 14 May 2025 18:16:22 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter has updated the pull request incrementally with one > additional commit since the last revision: > > 8354724: Replace getChars in previous commit with subS

  1   2   >