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

2025-03-03 Thread Jaikiran Pai
> 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://bugs.openjdk.org/browse/JDK-8066583 some of the > construct

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

2025-03-03 Thread Jaikiran Pai
On Sat, 1 Mar 2025 07:50:44 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: 8350682: [JMH] vector.IndexInRangeBenchmark failed with IndexOutOfBoundsException for size=1024

2025-03-03 Thread duke
On Tue, 25 Feb 2025 19:06:05 GMT, Vladimir Ivanov wrote: > Array initialization by parameter was added. Extra constant was used to align > cycle step with used arrays. @IvaVladimir Your change (at version 6f3450752f812bbc5fea4fdd9ecf2e9110c94229) is now ready to be sponsored by a Committer.

Re: adding Xalan's XSL 3 implementation within jdk

2025-03-03 Thread Joe Wang
On 3/1/25 10:19 PM, Mukul Gandhi wrote: Hi Joe,     Thanks for nice thoughts. On Fri, 28 Feb, 2025, 00:06 Joe Wang, wrote: What's your assessment on the readiness for a formal release (or how much additional work is needed)? What are the conformance test results? The link here,

Integrated: 8349516: StAXStream2SAX.handleCharacters() fails on empty CDATA

2025-03-03 Thread Joe Wang
On Fri, 28 Feb 2025 17:42:24 GMT, Joe Wang wrote: > Fix handleCharacters by adding a guard to zero length and letting the rest of > the process continue (e.g. closing tags and etc). This pull request has now been integrated. Changeset: 96613cc5 Author:Joe Wang URL: https://git.open

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v12]

2025-03-03 Thread Joe Darcy
On Sat, 15 Feb 2025 21:27:56 GMT, Archie Cobbs wrote: >> Please review this patch which removes unnecessary `@SuppressWarnings` >> annotations. > > Archie Cobbs has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 22 commits: > > - Me

Re: [External] : Re: RFR: 8350594: Misleading warning about install dir for DMG packaging

2025-03-03 Thread Michael Hall
> On Mar 3, 2025, at 1:51 PM, Michael Hall wrote: > > > >> On Mar 3, 2025, at 1:37 PM, Alexey Semenyuk >> wrote: >> >> Hi Michael, >> >> Thank you for the detailed report! I filed [1] ticket that, I hope, captures >> all findings from your report. Let me know if anything was missed or >

Re: RFR: 8351074: Disallow null prefix and suffix in DecimalFormat [v2]

2025-03-03 Thread Justin Lu
> Please review this PR and associated CSR which disallows passing null to 4 > `DecimalFormat` prefix/suffix setter methods. > > Currently these setters do not check the input String for null. When the > prefix/suffix is null, any such DecimalFormat instances are effectively > non-functional as

RFR: 8351074: Disallow null prefix and suffix in DecimalFormat

2025-03-03 Thread Justin Lu
Please review this PR and associated CSR which disallows passing null to 4 `DecimalFormat` prefix/suffix setter methods. Currently these setters do not check the input String for null. When the prefix/suffix is null, any such DecimalFormat instances are effectively non-functional as it will thr

Re: RFR: 8349516: StAXStream2SAX.handleCharacters() fails on empty CDATA [v3]

2025-03-03 Thread Naoto Sato
On Mon, 3 Mar 2025 19:24:38 GMT, Joe Wang wrote: >> Fix handleCharacters by adding a guard to zero length and letting the rest >> of the process continue (e.g. closing tags and etc). > > Joe Wang has updated the pull request incrementally with one additional > commit since the last revision: >

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

2025-03-03 Thread Lance Andersen
On Mon, 3 Mar 2025 11:59:36 GMT, Eirik Bjørsnøs wrote: > > Given the inputs from Alan, Eirik and Lance, I have now updated this PR > > [...] > > > Does this look better? > > I like the structure this is shaping into, with the affected constructors > linking into a note. I like that the note e

Integrated: 8350682: [JMH] vector.IndexInRangeBenchmark failed with IndexOutOfBoundsException for size=1024

2025-03-03 Thread Vladimir Ivanov
On Tue, 25 Feb 2025 19:06:05 GMT, Vladimir Ivanov wrote: > Array initialization by parameter was added. Extra constant was used to align > cycle step with used arrays. This pull request has now been integrated. Changeset: 768b0241 Author:Vladimir Ivanov Committer: Derek White URL:

Re: RFR: 8350682: [JMH] vector.IndexInRangeBenchmark failed with IndexOutOfBoundsException for size=1024

2025-03-03 Thread Vladimir Ivanov
On Tue, 25 Feb 2025 19:06:05 GMT, Vladimir Ivanov wrote: > Array initialization by parameter was added. Extra constant was used to align > cycle step with used arrays. Thanks for your review! - PR Comment: https://git.openjdk.org/jdk/pull/23783#issuecomment-2695524548

Re: RFR: 8350682: [JMH] vector.IndexInRangeBenchmark failed with IndexOutOfBoundsException for size=1024

2025-03-03 Thread Sandhya Viswanathan
On Tue, 25 Feb 2025 19:06:05 GMT, Vladimir Ivanov wrote: > Array initialization by parameter was added. Extra constant was used to align > cycle step with used arrays. Looks good to me. - Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/2

RFR: 8350811: [JMH] test foreign.StrLenTest failed with StringIndexOutOfBoundsException for size=451

2025-03-03 Thread Vladimir Ivanov
test setup was updated to generate data of requested size. - Commit messages: - JDK-8350811 [JMH] test foreign.StrLenTest failed with StringIndexOutOfBoundsException for size=451 Changes: https://git.openjdk.org/jdk/pull/23873/files Webrev: https://webrevs.openjdk.org/?repo=jdk&p

Re: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v5]

2025-03-03 Thread Ivan Walulya
On Mon, 3 Mar 2025 08:42:05 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: >> Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the

Re: [External] : Re: RFR: 8350594: Misleading warning about install dir for DMG packaging

2025-03-03 Thread Michael Hall
> On Mar 3, 2025, at 1:37 PM, Alexey Semenyuk > wrote: > > Hi Michael, > > Thank you for the detailed report! I filed [1] ticket that, I hope, captures > all findings from your report. Let me know if anything was missed or > misunderstood. > > [1] https://bugs.openjdk.org/browse/JDK-835107

Re: [External] : Re: RFR: 8350594: Misleading warning about install dir for DMG packaging

2025-03-03 Thread Alexey Semenyuk
Hi Michael, Thank you for the detailed report! I filed [1] ticket that, I hope, captures all findings from your report. Let me know if anything was missed or misunderstood. [1] https://bugs.openjdk.org/browse/JDK-8351073 - Alexey On 2/28/2025 10:39 PM, Michael Hall wrote: On Feb 27, 2025

Re: RFR: 8349516: StAXStream2SAX.handleCharacters() fails on empty CDATA [v2]

2025-03-03 Thread Joe Wang
On Mon, 3 Mar 2025 18:01:48 GMT, Naoto Sato wrote: >> Joe Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> remove commented section > > test/jaxp/javax/xml/jaxp/unittest/validation/ValidationTest.java line 151: > >> 149: * >> 1

Re: RFR: 8349516: StAXStream2SAX.handleCharacters() fails on empty CDATA [v3]

2025-03-03 Thread Joe Wang
> Fix handleCharacters by adding a guard to zero length and letting the rest of > the process continue (e.g. closing tags and etc). Joe Wang has updated the pull request incrementally with one additional commit since the last revision: improve the javadoc for the test - Changes:

Re: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v6]

2025-03-03 Thread Thomas Schatzl
> Hi all, > > please review this change that implements (currently Draft) JEP: G1: > Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP > process is already taking very long with no end in sight

Re: RFR: 8349516: StAXStream2SAX.handleCharacters() fails on empty CDATA [v2]

2025-03-03 Thread Naoto Sato
On Sat, 1 Mar 2025 01:19:17 GMT, Joe Wang wrote: >> Fix handleCharacters by adding a guard to zero length and letting the rest >> of the process continue (e.g. closing tags and etc). > > Joe Wang has updated the pull request incrementally with one additional > commit since the last revision: >

Re: RFR: 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method [v11]

2025-03-03 Thread Stuart Marks
On Mon, 3 Mar 2025 10:15:53 GMT, David Beaumont wrote: >> 8349206: j.u.l.Handler classes create deadlock risk via synchronized >> publish() method. >> >> 1. Remove synchronization of calls to publish() in Handlers in >> java.util.logging package. >> 2. Add explanatory comments to various affec

RFR: 8346118: Improve whitespace normalization in preformatted text

2025-03-03 Thread Hannes Wallnöfer
Please review an enhancement to make `DocCommentParser` normalize whitespace inside `` elements. The normalization is conceptually simple and and intended to be minimally invasive. Before parsing, `DocCommentParser` checks whether the text is a traditional doc comment and whether every line star

Re: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v5]

2025-03-03 Thread Thomas Schatzl
On Mon, 3 Mar 2025 15:17:27 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one >> additional commit since the last revision: >> >> * fix comment (trailing whitespace) >> * another assert when snapshotting at a safepoint. > > src/hotspot/sha

Re: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v5]

2025-03-03 Thread Thomas Schatzl
On Mon, 3 Mar 2025 14:47:00 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one >> additional commit since the last revision: >> >> * fix comment (trailing whitespace) >> * another assert when snapshotting at a safepoint. > > src/hotspot/sha

Re: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v5]

2025-03-03 Thread Thomas Schatzl
On Mon, 3 Mar 2025 14:11:09 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one >> additional commit since the last revision: >> >> * fix comment (trailing whitespace) >> * another assert when snapshotting at a safepoint. > > src/hotspot/cpu

RFR: 8351045: ClassValue::remove cannot ensure computation observes up-to-date state

2025-03-03 Thread Chen Liang
After a call to `ClassValue.remove`, a `ClassValue` can still install a value that is computed with information that is not up-to-date with the remove call. This is demonstrated in the test case, where an innocuous `ClassValue.get` call on an uncomputed CV may happen to compute during which a re

Re: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v5]

2025-03-03 Thread Albert Mingkun Yang
On Mon, 3 Mar 2025 08:42:05 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: >> Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the

Re: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v5]

2025-03-03 Thread Amit Kumar
On Mon, 3 Mar 2025 08:42:05 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: >> Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the

Re: RFR: 8350685: java/lang/System/SecurityManagerWarnings.java fails with --enable-preview

2025-03-03 Thread Sean Mullan
On Mon, 3 Mar 2025 13:33:05 GMT, Sean Mullan wrote: > Please review this fix to a test that fails when run with --enable-preview. > This fix is to add all the necessary utility classes imported by the test to > the JAR file, and not just the test classes. test/jdk/java/lang/System/SecurityMana

RFR: 8350685: java/lang/System/SecurityManagerWarnings.java fails with --enable-preview

2025-03-03 Thread Sean Mullan
Please review this fix to a test that fails when run with --enable-preview. This fix is to add all the necessary utility classes imported by the test to the JAR file, and not just the test classes. - Commit messages: - Initial fix. Changes: https://git.openjdk.org/jdk/pull/23864/f

Re: RFR: 8319447: Improve performance of delayed task handling [v6]

2025-03-03 Thread Doug Lea
On Sun, 2 Mar 2025 15:49:26 GMT, Viktor Klang wrote: >> Doug Lea has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Reduce volatile reads > > src/java.base/share/classes/java/util/concurrent/DelayScheduler.java line 255: > >> 253:

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

2025-03-03 Thread Eirik Bjørsnøs
On Sat, 1 Mar 2025 07:50:44 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: 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method [v11]

2025-03-03 Thread Daniel Fuchs
On Mon, 3 Mar 2025 10:15:53 GMT, David Beaumont wrote: >> 8349206: j.u.l.Handler classes create deadlock risk via synchronized >> publish() method. >> >> 1. Remove synchronization of calls to publish() in Handlers in >> java.util.logging package. >> 2. Add explanatory comments to various affec

Re: RFR: 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method [v11]

2025-03-03 Thread David Beaumont
> 8349206: j.u.l.Handler classes create deadlock risk via synchronized > publish() method. > > 1. Remove synchronization of calls to publish() in Handlers in > java.util.logging package. > 2. Add explanatory comments to various affected methods. > 3. Add a test to ensure deadlocks no longer occu

Re: RFR: 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method [v10]

2025-03-03 Thread David Beaumont
On Sun, 2 Mar 2025 03:16:02 GMT, Jason Mehrens wrote: >> I'd have to disagree with the points you make. >> >> The fact is that loggers are never expected to modify the passed parameters. >> To ask people to "disown" the parameters they pass to a logger requires that >> your best advice on how

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

2025-03-03 Thread Volkan Yazici
On Sat, 1 Mar 2025 07:50:44 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: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v5]

2025-03-03 Thread Thomas Schatzl
> Hi all, > > please review this change that implements (currently Draft) JEP: G1: > Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP > process is already taking very long with no end in sight