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
> 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.
-
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
> 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
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
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"?
>
>
> 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
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
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:
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
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.
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.
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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 (
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"
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
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
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
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
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
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;
>
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
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
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
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
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
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);
>>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 `
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
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
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
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
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
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
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
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
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
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
* 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
---
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
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
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
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
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
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
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
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
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
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
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.
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()
-
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
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
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
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
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
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
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
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
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
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
>
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
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, "
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/
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
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 - 100 of 561 matches
Mail list logo