Re: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty pointing to newer APIs [v4]

2025-06-12 Thread Stuart Marks
On Thu, 12 Jun 2025 23:39:44 GMT, Stuart Marks wrote: >> Add a note to String.trim pointing to the String.strip family of methods. >> >> Add notes cross-linking String.isBlank and String.isEmpty. > > Stuart Marks has updated the pull request incrementally with one additi

Re: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty pointing to newer APIs [v4]

2025-06-12 Thread Stuart Marks
> Add a note to String.trim pointing to the String.strip family of methods. > > Add notes cross-linking String.isBlank and String.isEmpty. Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: More wording updates. -

Re: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty pointing to newer APIs [v4]

2025-06-12 Thread Stuart Marks
On Thu, 12 Jun 2025 23:21:15 GMT, Stuart Marks wrote: >>> I'd describe this as "space plus ASCII control characters." Would something >>> like that make more sense? >> >> Yeah, I think so > > OK, I've updated the wording. Let me know if

Re: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty pointing to newer APIs [v3]

2025-06-12 Thread Stuart Marks
> Add a note to String.trim pointing to the String.strip family of methods. > > Add notes cross-linking String.isBlank and String.isEmpty. Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: Update wording per s

Re: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty pointing to newer APIs [v3]

2025-06-12 Thread Stuart Marks
On Thu, 12 Jun 2025 01:54:40 GMT, Naoto Sato wrote: >> Oh yeah, that should be "an ASCII" >> >> But maybe we should change the wording per @naotoj's comment. I don't want >> to repeat the specification above, but rather I want to describe it in terms >> of what the thinking was at the time

Re: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty pointing to newer APIs

2025-06-11 Thread Stuart Marks
On Wed, 11 Jun 2025 23:57:48 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/lang/String.java line 3837: >> >>> 3835: * >>> 3836: * @apiNote >>> 3837: * This method uses a ASCII-based definition of space characters >>> that are to be >> >> "a ASCII" or "an ASCII"? > >

Re: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty pointing to newer APIs [v2]

2025-06-11 Thread Stuart Marks
> Add a note to String.trim pointing to the String.strip family of methods. > > Add notes cross-linking String.isBlank and String.isEmpty. Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: Use {@return ...} i

Re: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty pointing to newer APIs [v2]

2025-06-11 Thread Stuart Marks
On Thu, 12 Jun 2025 00:35:12 GMT, Stuart Marks wrote: >> src/java.base/share/classes/java/lang/String.java line 3937: >> >>> 3935: >>> 3936: /** >>> 3937: * Returns {@code true} if the string is empty or contains only >> >> This

Re: RFR: 8338140: (str) Add notes to String.trim and String.isEmpty pointing to newer APIs

2025-06-11 Thread Stuart Marks
On Wed, 11 Jun 2025 23:57:02 GMT, Justin Lu wrote: >> Add a note to String.trim pointing to the String.strip family of methods. >> >> Add notes cross-linking String.isBlank and String.isEmpty. > > src/java.base/share/classes/java/lang/String.java line 3937: > >> 3935: >> 3936: /** >> 3937:

RFR: 8338140: (str) Add notes to String.trim and String.isEmpty pointing to newer APIs

2025-06-11 Thread Stuart Marks
Add a note to String.trim pointing to the String.strip family of methods. Add notes cross-linking String.isBlank and String.isEmpty. - Commit messages: - Updates to String javadoc. Changes: https://git.openjdk.org/jdk/pull/25762/files Webrev: https://webrevs.openjdk.org/?repo=jdk

[jdk25] Integrated: 8358809: Improve link to stdin.encoding from java.lang.IO

2025-06-06 Thread Stuart Marks
On Fri, 6 Jun 2025 22:07:38 GMT, Stuart Marks wrote: > Hi all, > > This pull request contains a backport of commit > [d024f58e](https://github.com/openjdk/jdk/commit/d024f58e61ec27f6c13fde5dadb95c31875815d6) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

Re: [jdk25] RFR: 8358809: Improve link to stdin.encoding from java.lang.IO

2025-06-06 Thread Stuart Marks
On Fri, 6 Jun 2025 22:07:38 GMT, Stuart Marks wrote: > Hi all, > > This pull request contains a backport of commit > [d024f58e](https://github.com/openjdk/jdk/commit/d024f58e61ec27f6c13fde5dadb95c31875815d6) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

[jdk25] RFR: 8358809: Improve link to stdin.encoding from java.lang.IO

2025-06-06 Thread Stuart Marks
Hi all, This pull request contains a backport of commit [d024f58e](https://github.com/openjdk/jdk/commit/d024f58e61ec27f6c13fde5dadb95c31875815d6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Stuart Marks on 6 Jun 2025 and was

Integrated: 8358809: Improve link to stdin.encoding from java.lang.IO

2025-06-06 Thread Stuart Marks
On Fri, 6 Jun 2025 18:34:10 GMT, Stuart Marks wrote: > Use a link of the form `System##stdin.encoding` to link directly to the > system property's description. This pull request has now been integrated. Changeset: d024f58e Author:Stuart Marks URL: https://git.open

RFR: 8358809: better link to stdin.encoding from java.lang.IO

2025-06-06 Thread Stuart Marks
Use a link of the form `System##stdin.encoding` to link directly to the system property's description. - Commit messages: - 8358809: better link to stdin.encoding from java.lang.IO Changes: https://git.openjdk.org/jdk/pull/25676/files Webrev: https://webrevs.openjdk.org/?repo=jdk

Re: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]

2025-06-04 Thread Stuart Marks
On Wed, 4 Jun 2025 16:04:08 GMT, Erik Gahlin wrote: >> src/java.base/share/classes/java/net/Socket.java line 970: >> >>> 968: long end = SocketReadEvent.timestamp(); >>> 969: long duration = end - start; >>> 970: if (SocketReadEvent.shouldThrottleCommit(durati

Re: RFR: 8358015: Fix SequencedMap sequenced view method specifications [v2]

2025-06-04 Thread Stuart Marks
On Wed, 4 Jun 2025 16:50:15 GMT, Johannes Döbler wrote: >> Interesting. This `@NoOverride` idea could be useful on a subclass that >> wants to make sure it overrides everything. (Maybe `@NoInherit` would be a >> better name.) Meanwhile for JDK-8357272 (PR >> https://github.com/openjdk/jdk/pull

Re: RFR: 8358015: Fix SequencedMap sequenced view method specifications [v2]

2025-06-04 Thread Stuart Marks
On Wed, 4 Jun 2025 04:08:36 GMT, Joe Darcy wrote: >> The `@Override` annotation has been inconsistently applied in the >> collections implementations. In practice since so many methods are >> overridden, and some test would likely fail if a method weren't overridden >> properly, the annotation

Integrated: 8358015: Fix SequencedMap sequenced view method specifications

2025-06-04 Thread Stuart Marks
On Thu, 29 May 2025 00:21:35 GMT, Stuart Marks wrote: > For a full explanation, see the bug report > [JDK-8358015](https://bugs.openjdk.org/browse/JDK-8358015). > > This PR includes three related changes: > * New overrides in SequencedMap view collection implementations, which

Re: RFR: 8358015: Fix SequencedMap sequenced view method specifications [v3]

2025-06-03 Thread Stuart Marks
c` clauses to reflect this behavior (which was > previously ill-specified). > * Update to a test which relied on unspecified behavior. Stuart Marks 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 i

Re: RFR: 8358015: Fix SequencedMap sequenced view method specifications [v2]

2025-06-03 Thread Stuart Marks
On Mon, 2 Jun 2025 20:41:41 GMT, Joe Darcy wrote: >> Stuart Marks has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Tweak nsee() declaration; adjust specs per suggestion; update copyrights. > > src/jav

Re: RFR: 8357798: ReverseOrderListView uses Boolean boxes after JDK-8356080 [v2]

2025-06-03 Thread Stuart Marks
On Mon, 2 Jun 2025 13:26:36 GMT, Aleksey Shipilev wrote: >> SonarCloud complains that since >> [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using >> `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> >> `Boolean` was made in >> [JDK-8356080](https://bugs.

Re: RFR: 8358015: Fix SequencedMap sequenced view method specifications [v2]

2025-05-30 Thread Stuart Marks
c` clauses to reflect this behavior (which was > previously ill-specified). > * Update to a test which relied on unspecified behavior. Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: Tweak nsee() declaration; adjust specs per su

Re: RFR: 8358015: Fix SequencedMap sequenced view method specifications

2025-05-30 Thread Stuart Marks
On Fri, 30 May 2025 14:38:19 GMT, Jaikiran Pai wrote: >> Overall this looks good to me. I just have a small question about the newly >> introduced text. >> >> The copyright years on BasicMap.java and SequencedMap.java will need a >> update before integrating. > >> I just have a small question

Re: RFR: 8358015: Fix SequencedMap sequenced view method specifications

2025-05-30 Thread Stuart Marks
On Fri, 30 May 2025 14:33:05 GMT, Jaikiran Pai wrote: >> For a full explanation, see the bug report >> [JDK-8358015](https://bugs.openjdk.org/browse/JDK-8358015). >> >> This PR includes three related changes: >> * New overrides in SequencedMap view collection implementations, which >> improve

Re: RFR: 8358015: Fix SequencedMap sequenced view method specifications

2025-05-30 Thread Stuart Marks
On Thu, 29 May 2025 19:44:20 GMT, ExE Boss wrote: >> For a full explanation, see the bug report >> [JDK-8358015](https://bugs.openjdk.org/browse/JDK-8358015). >> >> This PR includes three related changes: >> * New overrides in SequencedMap view collection implementations, which >> improve thei

Re: RFR: 8358015: Fix SequencedMap sequenced view method specifications

2025-05-30 Thread Stuart Marks
On Fri, 30 May 2025 02:33:27 GMT, Chen Liang wrote: >> For a full explanation, see the bug report >> [JDK-8358015](https://bugs.openjdk.org/browse/JDK-8358015). >> >> This PR includes three related changes: >> * New overrides in SequencedMap view collection implementations, which >> improve th

Re: RFR: 8328821: Map.of() derived view collection mutators should throw UnsupportedOperationException [v11]

2025-05-29 Thread Stuart Marks
On Fri, 30 May 2025 02:23:17 GMT, Liam Miller-Cushon wrote: > I have reviewed the CSR for you. Maybe us, Per Minborg, and Stuart Marks can > work together to get the two significant collection changes into early 26 and > broadcast on quality discuss list, as otherwise corpus analysis

RFR: 8358015: Fix SequencedMap sequenced view method specifications

2025-05-29 Thread Stuart Marks
For a full explanation, see the bug report [JDK-8358015](https://bugs.openjdk.org/browse/JDK-8358015). This PR includes three related changes: * New overrides in SequencedMap view collection implementations, which improve their behavior. * Update to `@implSpec` clauses to reflect this behavior (

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

2025-05-27 Thread Stuart Marks
On Fri, 23 May 2025 18:44:42 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: "input reader specific" -> "reader specific"

Re: RFR: 8357798: ReverseOrderListView uses Boolean boxes after JDK-8356080

2025-05-27 Thread Stuart Marks
On Mon, 26 May 2025 17:08:45 GMT, Aleksey Shipilev wrote: > SonarCloud complains that since > [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using > `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean` > was made in [JDK-8356080](https://bugs.openjdk

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

2025-05-23 Thread Stuart Marks
On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato wrote: >> `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 >> diff

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

2025-05-23 Thread Stuart Marks
On Fri, 23 May 2025 16:26:36 GMT, Naoto Sato wrote: > Can they even possibly do so? Sure, as far as I know, IntelliJ IDEA runs on its own version of the JDK, and it can easily be invoked or modified to allow use of those modules. I took a quick look at NetBeans and didn't see any references to

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

2025-05-22 Thread Stuart Marks
On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato wrote: >> `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 >> diff

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

2025-05-22 Thread Stuart Marks
On Wed, 21 May 2025 16:48:20 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/io/Console.java line 67: >> >>> 65: * stdout.encoding}, in which case read operations use the {@code >>> Charset} >>> 66: * designated by {@code stdin.encoding}. >>> 67: * >> >> `Console.charset()` stat

Integrated: 8351230: Collections.synchronizedList returns a list that is not thread-safe

2025-05-19 Thread Stuart Marks
On Thu, 1 May 2025 19:05:50 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; >

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

2025-05-16 Thread Stuart Marks
views; > - adds test for race conditions and functional tests of synchronized wrappers. Stuart Marks 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 e

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

2025-05-16 Thread Stuart Marks
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 t

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

2025-05-16 Thread Stuart Marks
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 t

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

2025-05-14 Thread Stuart Marks
On Wed, 14 May 2025 17:53:48 GMT, Markus KARG wrote: >> The code should use the three-arg read() call in order to limit self-calls, >> in order to avoid the fragile base class problem. At some point we might >> want to add implSpec tags to specify this. See my previous comments relate >> to th

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

2025-05-14 Thread Stuart Marks
On Wed, 14 May 2025 21:02:20 GMT, Markus KARG wrote: >> Both `subSequence` and `getChars` are implemented by the CharSequence. >> They have the same level of trustworthiness about their implementation. > > I meant that the implementation of `subSequence` *might or might not* perform > copy (so w

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

2025-05-14 Thread Stuart Marks
On Wed, 14 May 2025 17:40:53 GMT, Brian Burkhalter wrote: >> All other self-calls to a `read` method are to the three-arg abstract method: >> >> $ grep read( src/java.base/share/classes/java/io/Reader.java | grep -v >> public | grep -v * >> nread = this.read(cbuf, off, rem); >>

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

2025-05-14 Thread Stuart Marks
On Tue, 13 May 2025 15:33:39 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: "stream" -> "reader" src/java.base/share/cla

Re: RFR: 8356420: Provide examples on wrapping System.in [v6]

2025-05-12 Thread Stuart Marks
On Tue, 13 May 2025 03:15:25 GMT, Naoto Sato wrote: >> With the introduction of `stdin.encoding` >> ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance >> for users to decode `System.in` would be desirable. Adding examples in the >> field description would help. > > Nao

Re: RFR: 8356420: Provide examples on wrapping System.in [v4]

2025-05-12 Thread Stuart Marks
On Mon, 12 May 2025 21:59:29 GMT, Naoto Sato wrote: >> With the introduction of `stdin.encoding` >> ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance >> for users to decode `System.in` would be desirable. Adding examples in the >> field description would help. > > Nao

Re: RFR: 8356420: Provide examples on wrapping System.in [v4]

2025-05-12 Thread Stuart Marks
On Mon, 12 May 2025 21:59:29 GMT, Naoto Sato wrote: >> With the introduction of `stdin.encoding` >> ([JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703)), some guidance >> for users to decode `System.in` would be desirable. Adding examples in the >> field description would help. > > Nao

Re: RFR: 8356486: ReverseOrderListView should override reversed() to return `base` [v2]

2025-05-09 Thread Stuart Marks
On Fri, 9 May 2025 07:50:29 GMT, Per Minborg wrote: >> This PR proposed to let `ReverseOrderListView::reversed` directly return >> `base` instead of going though a more complicated code path. > > Per Minborg has updated the pull request incrementally with two additional > commits since the last

Re: RFR: 8356486: ReverseOrderListView should override reversed() to return `base` [v2]

2025-05-09 Thread Stuart Marks
On Fri, 9 May 2025 07:03:30 GMT, Per Minborg wrote: >> There are some new collections (such as StableList) that are not covered in >> Basic. But maybe they should have their separate tests? > > `UnmodifiableSequencedCollection` double-reversed is not an identity > function. But at least, it doe

Re: RFR: 8356486: ReverseOrderListView::reversed should return `base`

2025-05-08 Thread Stuart Marks
On Thu, 8 May 2025 14:30:28 GMT, Per Minborg wrote: > This PR proposed to let `ReverseOrderListView::reversed` return `base` so > that nested reversed views are avoided. src/java.base/share/classes/java/util/ReverseOrderListView.java line 398: > 396: } > 397: > 398: @Override I don't

Re: RFR: 8356080: Address post-integration comments for Stable Values

2025-05-08 Thread Stuart Marks
On Fri, 2 May 2025 12:13:39 GMT, Per Minborg wrote: > This PR proposes to address comments in the initial PR for Stable Values, > which were deferred until after integration. > > Unfortunately, this PR shows the total commit history for stable values. src/java.base/share/classes/java/util/Immu

Re: RFR: 8356486: ReverseOrderListView::reversed should return `base`

2025-05-08 Thread Stuart Marks
On Thu, 8 May 2025 14:44:26 GMT, Chen Liang wrote: >> This PR proposed to let `ReverseOrderListView::reversed` return `base` so >> that nested reversed views are avoided. > > test/jdk/java/util/Collection/MOAT.java line 507: > >> 505: private static void testImmutableSeqColl(final >> Sequ

Re: RFR: 8356486: ReverseOrderListView::reversed should return `base`

2025-05-08 Thread Stuart Marks
On Thu, 8 May 2025 14:30:28 GMT, Per Minborg wrote: > This PR proposed to let `ReverseOrderListView::reversed` return `base` so > that nested reversed views are avoided. I think there are already tests to ensure that list.reversed().reversed() returns the original list. See also https://github

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

2025-05-05 Thread Stuart Marks
On Sun, 4 May 2025 17:51:48 GMT, Luca Kellermann 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 t

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

2025-05-05 Thread Stuart Marks
views; > - adds test for race conditions and functional tests of synchronized wrappers. 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

Re: RFR: 8354724: BufferedReader readAllLines and readString methods [v14]

2025-05-02 Thread Stuart Marks
On Wed, 23 Apr 2025 22:04:25 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: Fix readAllChars gaffe in Reader returned by

Re: RFR: 8354724: BufferedReader readAllLines and readString methods [v14]

2025-05-02 Thread Stuart Marks
On Thu, 1 May 2025 19:19:32 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/io/Reader.java line 408: >> >>> 406: * This method works as if invoking it were equivalent to >>> evaluating >>> 407: * the expression: >>> 408: * {@linkplain >>> #readAllChars()}.lines().to

RFR: 8351230: Collections.synchronizedList returns a list that is not thread-safe

2025-05-02 Thread Stuart Marks
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 for race con

Re: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance Main Methods [v8]

2025-05-01 Thread Stuart Marks
On Thu, 1 May 2025 18:43:57 GMT, Chen Liang wrote: >> Jan Lahoda has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Updating copyright year. > > src/java.base/share/classes/java/lang/IO.java line 157: > >> 155: * >> 156: * Write

Re: RFR: 8354724: BufferedReader readAllLines and readString methods [v14]

2025-05-01 Thread Stuart Marks
On Wed, 23 Apr 2025 22:04:25 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: Fix readAllChars gaffe in Reader returned by

Re: RFR: 8354724: BufferedReader readAllLines and readString methods [v14]

2025-05-01 Thread Stuart Marks
On Wed, 23 Apr 2025 22:04:25 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: Fix readAllChars gaffe in Reader returned by

Re: RFR: 8354724: BufferedReader readAllLines and readString methods [v14]

2025-05-01 Thread Stuart Marks
On Wed, 23 Apr 2025 22:04:25 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: Fix readAllChars gaffe in Reader returned by

Re: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance Main Methods [v5]

2025-05-01 Thread Stuart Marks
On Thu, 1 May 2025 09:51:41 GMT, Tatsunori Uchino wrote: >> Anyway you need to merge master first to test `stdin.encoding`. > > `stdin.encoding` seems to work as intended in Windows for Japanese. (I > managed to get the Windows binary of my PR) No need to change. (I wish the > constructors of `

Re: RFR: 8355632: WhiteBox.waitForReferenceProcessing() fails assert for return type

2025-04-25 Thread Stuart Marks
On Fri, 25 Apr 2025 23:37:13 GMT, Brent Christian wrote: > The newly-added `WhiteBox.waitForReferenceProcessing()` (see > [8305186](https://bugs.openjdk.org/browse/JDK-8305186)) always fails with > assertions enabled. > I've updated the assertion, and also added the test I used locally to test

Integrated: 8350703: Add standard system property stdin.encoding

2025-04-25 Thread Stuart Marks
On Thu, 17 Apr 2025 18:59:33 GMT, Stuart Marks wrote: > * Windows and Unix: set sprops.stdin_encoding if connected to a console > * Add specs for stdin.encoding > * Adjust specs to change "undefined" to "unspecified" > * Rewrite System.in spec to refer to new pr

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

2025-04-24 Thread Stuart Marks
On Tue, 22 Apr 2025 18:56:40 GMT, Stuart Marks wrote: >> src/java.base/share/classes/java/lang/IO.java line 41: >> >>> 39: * The {@link #readln()} and {@link #readln(String)} methods decode >>> bytes read from >>> 40: * {@code System.in} into chara

Re: RFR: 8354424: java/util/logging/LoggingDeadlock5.java fails intermittently in tier6 [v2]

2025-04-24 Thread Stuart Marks
On Wed, 16 Apr 2025 17:37:07 GMT, David Beaumont wrote: >> Increasing timeout for deadlock detection and adjusting for the timeout >> factor in higher tiers. > > David Beaumont has updated the pull request incrementally with one additional > commit since the last revision: > > Removing test

Re: RFR: 8354424: java/util/logging/LoggingDeadlock5.java fails intermittently in tier6 [v2]

2025-04-24 Thread Stuart Marks
On Tue, 22 Apr 2025 13:53:14 GMT, Daniel Fuchs wrote: >> test/jdk/java/util/logging/LoggingDeadlock5.java line 127: >> >>> 125: // in higher tiers, so it's necessary to be a bit pessimistic >>> here. >>> 126: private final static Duration JOIN_WAIT = >>> 127: Dur

Re: RFR: 8350703: Add standard system property stdin.encoding [v3]

2025-04-23 Thread Stuart Marks
m encoding > * Update property test Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: Yet another minor bit of wordsmithing. - Changes: - all: https://git.openjdk.org/jdk/pull/24738/files - new: https://git.ope

Re: RFR: 8350703: Add standard system property stdin.encoding

2025-04-23 Thread Stuart Marks
On Thu, 17 Apr 2025 18:59:33 GMT, Stuart Marks wrote: > * Windows and Unix: set sprops.stdin_encoding if connected to a console > * Add specs for stdin.encoding > * Adjust specs to change "undefined" to "unspecified" > * Rewrite System.in spec to refer to new pr

Re: RFR: 8350703: Add standard system property stdin.encoding [v2]

2025-04-23 Thread Stuart Marks
On Wed, 23 Apr 2025 01:34:42 GMT, Naoto Sato wrote: >> Stuart Marks has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update sun.stdout/err.encoding comments; tweak Windows file handle >> variable name. &g

Re: RFR: 8350703: Add standard system property stdin.encoding [v2]

2025-04-23 Thread Stuart Marks
m encoding > * Update property test Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: Update sun.stdout/err.encoding comments; tweak Windows file handle variable name. - Changes: - all: https://git.openjdk.o

Re: RFR: 8350703: Add standard system property stdin.encoding [v2]

2025-04-23 Thread Stuart Marks
On Wed, 23 Apr 2025 12:54:29 GMT, Alan Bateman wrote: >> src/java.base/share/classes/jdk/internal/util/SystemProps.java line 92: >> >>> 90: >>> 91: // Encoding properties for stdin, stdout, and stderr. For >>> stdout and stderr, >>> 92: // check "sun.*.encoding" properties befo

RFR: 8350703: Add standard system property stdin.encoding

2025-04-22 Thread Stuart Marks
* Windows and Unix: set sprops.stdin_encoding if connected to a console * Add specs for stdin.encoding * Adjust specs to change "undefined" to "unspecified" * Rewrite System.in spec to refer to new property and to clarify usage with classes that perform encoding * Update property test ---

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

2025-04-22 Thread Stuart Marks
s stdin.encoding} property. If this >> property is not present, > > @stuart-marks Are you planning to propose/integrate pull/24738 in advance of > the JEP update? Asking because this paragraph will need to be adjusted if > pull/24738 doesn't go in first. Depends on how close you

Re: RFR: 8354724: BufferedReader readAllLines and readString methods [v5]

2025-04-18 Thread Stuart Marks
On Thu, 17 Apr 2025 23:07:35 GMT, Brian Burkhalter wrote: >> Implement the requested methods and add a test thereof. > > Brian Burkhalter has updated the pull request incrementally with two > additional commits since the last revision: > > - 8354724: Increment copyright year in Reader > - 835

Re: RFR: 8354464: Additional cleanup setting up native.encoding [v2]

2025-04-18 Thread Stuart Marks
On Wed, 16 Apr 2025 13:20:33 GMT, Alan Bateman wrote: >> Stuart Marks 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 contai

Re: RFR: 8354724: BufferedReader readAllLines and readString methods [v4]

2025-04-17 Thread Stuart Marks
On Thu, 17 Apr 2025 22:13:06 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: Change the test to reuse a ByteBuffer when wr

Integrated: 8354464: Additional cleanup setting up native.encoding

2025-04-17 Thread Stuart Marks
On Sat, 12 Apr 2025 02:19:35 GMT, Stuart Marks wrote: > Remove the #ifdef MACOSX from platform-independent System.c, which (on Mac) > sets native.encoding from sprops.encoding or (on non-Mac Unix and Windows) > sets native.encoding from sprops.sun_jnu_encoding. After this rem

Re: RFR: 8354464: Additional cleanup setting up native.encoding [v2]

2025-04-17 Thread Stuart Marks
On Thu, 17 Apr 2025 00:26:49 GMT, Stuart Marks wrote: >> I belive they can be removed as they are no where used (and I don't think it >> will be used for `stdin.encoding` either) So I prefer removing those unused >> code now. > > OK, I've done so. Now testing

Re: RFR: 8354464: Additional cleanup setting up native.encoding [v3]

2025-04-17 Thread Stuart Marks
e other possibilities > here, such as changing the interface to SetupI18nProps(). I'm open to > suggestions. Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: Remove encoding parameter from SetupI18nProps. - Ch

Re: RFR: 8354464: Additional cleanup setting up native.encoding [v2]

2025-04-16 Thread Stuart Marks
On Wed, 16 Apr 2025 20:46:04 GMT, Naoto Sato wrote: >> The main focus of this commit is to straighten out the logic between the >> platform-specific and platform-independent layers. >> >> In the previous state of this file, tracing the origin of the properties on >> Windows, I ended up followi

Re: RFR: 8354464: Additional cleanup setting up native.encoding [v2]

2025-04-16 Thread Stuart Marks
On Wed, 16 Apr 2025 14:43:45 GMT, Roger Riggs wrote: >> Stuart Marks 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 four addi

Re: RFR: 8354464: Additional cleanup setting up native.encoding [v2]

2025-04-15 Thread Stuart Marks
On Tue, 15 Apr 2025 17:12:18 GMT, Naoto Sato wrote: >> src/java.base/share/native/libjava/System.c line 151: >> >>> 149: /* basic encoding properties, always non-NULL */ >>> 150: PUTPROP(propArray, _native_encoding_NDX, sprops->encoding); >>> 151: PUTPROP(propArray, _sun_jnu_encoding

Re: RFR: 8354464: Additional cleanup setting up native.encoding [v2]

2025-04-15 Thread Stuart Marks
e other possibilities > here, such as changing the interface to SetupI18nProps(). I'm open to > suggestions. Stuart Marks 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.

Re: [External] : Re: My experience using Java to do CLI Scripting

2025-04-15 Thread Stuart Marks
On 4/15/25 5:30 AM, Ron Pressler wrote: On 15 Apr 2025, at 10:51, fo...@univ-mlv.fr wrote: >> +1 for readAllInputLines() and readInputString() on Process. Wouldn’t it make more sense to add these to BufferedReader? Yes. Process already has four Reader-based overloads: - inputReader() -

Re: [External] : Re: My experience using Java to do CLI Scripting

2025-04-15 Thread Stuart Marks
On 4/14/25 11:52 PM, Cay Horstmann wrote: * How exactly do I use getInputStream()/inputReader() with *extreme care*, as the API doc warns me? Ah. This is referring to the following note in the Process.getInputStream() method spec: API Note: Use getInputStream() and inputReader() with

RFR: 8354464: Additional cleanup setting up native.encoding

2025-04-14 Thread Stuart Marks
Remove the #ifdef MACOSX from platform-independent System.c, which (on Mac) sets native.encoding from sprops.encoding or (on non-Mac Unix and Windows) sets native.encoding from sprops.sun_jnu_encoding. After this removal, the native.encoding property will be set from sprops.encoding and the sun

Re: My experience using Java to do CLI Scripting

2025-04-14 Thread Stuart Marks
On 4/14/25 1:48 PM, Remi Forax wrote: From: "Ron Pressler" This does what you want (and could even be combined to a single expression): Process p = new ProcessBuilder("ls", "-al").start(); String result = p.inputReader().lines().collect(Collectors.joining("\n")); and it’s even nicer

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

2025-04-14 Thread Stuart Marks
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

Re: RFR: 8305186: Reference.waitForReferenceProcessing should be more accessible to tests [v4]

2025-04-10 Thread Stuart Marks
On Thu, 10 Apr 2025 22:24:04 GMT, Brent Christian wrote: >> Certain specific types of tests involving GC and reference processing need >> to account for the delay between a GC completing (during which the GC clears >> a Reference), and the Reference being added to its associated queue. At >> p

Re: RFR: 8305186: Reference.waitForReferenceProcessing should be more accessible to tests [v3]

2025-04-10 Thread Stuart Marks
On Thu, 10 Apr 2025 22:18:20 GMT, Brent Christian wrote: >> test/lib/jdk/test/whitebox/WhiteBox.java line 570: >> >>> 568:* This method should usually be called after a call to >>> WhiteBox.fullGC(). >>> 569:*/ >>> 570: public static void waitForReferenceProcessing() { >> >> Referenc

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

2025-04-10 Thread Stuart Marks
On Mon, 7 Apr 2025 18:49:33 GMT, Chen Liang wrote: >> I used "internal objects" because I wanted to avoid naming concrete classes, >> which might or might not be used. Previous drafts mentioned BufferedReader, >> InputStreamReader, and CharsetDecoder. >> >> I could replace "internal objects" w

Integrated: 8351740: Clean up some code around initialization of encoding properties

2025-04-10 Thread Stuart Marks
On Fri, 4 Apr 2025 23:42:26 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-preserv

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

2025-04-10 Thread Stuart Marks
On Sat, 5 Apr 2025 02:31:21 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/IO.java line 122: >> >>> 120: public static void print(Object obj) { >>> 121: System.out.print(obj); >>> 122: System.out.flush(); >> >> Is it worth using a local variable to avoid cal

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

2025-04-10 Thread Stuart Marks
On Thu, 10 Apr 2025 18:14:52 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 >

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

2025-04-10 Thread Stuart Marks
java line 45: > >> 43: * UTF-8 is used instead. These internal objects are created upon the >> first call to >> 44: * either of the {@code readln} methods and are stored for subsequent >> reuse by these >> 45: * methods. > > @stuart-marks Can we rephr

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

2025-04-10 Thread Stuart Marks
On Thu, 10 Apr 2025 18:11:06 GMT, Stuart Marks wrote: >> src/java.base/share/classes/jdk/internal/util/SystemProps.java line 79: >> >>> 77: // Platform defined encodings cannot be overridden on the >>> command line >>> 78: put(props, "

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

2025-04-10 Thread Stuart Marks
On Thu, 10 Apr 2025 08:31:40 GMT, Alan Bateman wrote: >> Stuart Marks has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix comment from file.encoding to native.encoding > > src/java.base/share/classes/jdk/

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

2025-04-10 Thread Stuart Marks
ng_NDX. > > * In SystemProps.Raw.cmdProperties(), adjust the HashMap size computation. > This should actually avoid resizing of the HashMap (unlike the earlier code). > > * Adjust various comments in several places for clarity and correctness. Stuart Marks has updated the pu

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

2025-04-09 Thread Stuart Marks
On Wed, 9 Apr 2025 17:02:52 GMT, Stuart Marks wrote: >> The readln methods handle malformed-input and unmappable-character errors by >> dropping, and using a replacement value. So erroneous input doesn't throw >> IOError with a CharacterCodingException as the cause.

  1   2   3   4   5   6   >