On 27/06/2025 03:47, David Holmes wrote:
Hi Pavel,
On 27/06/2025 8:23 am, Pavel Rappo wrote:
Here's an interesting behaviour. A thread that has been blocked in
Object.wait is interrupted. But instead of throwing an
InterruptedException, Object.wait returns normally with the thread's
interrupt s
> Create a jar directly from the memory instead of real file, this should
> reduce the I/O overhead which likely the reason for the time out.
> The issue is not reproducible locally, and fails intermittently, so we simply
> trying to reduce time needed.
> The jar file created is verified manually
David,
As you correctly identified, the edge case that I mentioned is this:
concurrent interrupt and notify [^1]. It has nothing to do with
spurious wake-ups or virtual threads. In fact, I've seen that with
virtual threads Object.wait behaves exactly the same way as with
platform threads in that r
The ICU4J component currently stores binary data files directly in the
repository. This change replaces them with base64-encoded text files and
converts them to binary during the build process
-
Commit messages:
- initial commit
Changes: https://git.openjdk.org/jdk/pull/26027/file
On Fri, 27 Jun 2025 01:03:30 GMT, Kim Barrett wrote:
>> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
>> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
>> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
>>
On Mon, 19 May 2025 20:34:35 GMT, Kim Barrett wrote:
>> src/java.base/share/classes/sun/nio/Cleaner.java line 31:
>>
>>> 29: * {@code Cleaner} represents an object and a cleaning action.
>>> 30: */
>>> 31: public interface Cleaner {
>>
>> Can this be renamed NIOCleaner or NIOBufClenaer or som
On Fri, 27 Jun 2025 20:45:14 GMT, Naoto Sato wrote:
> The ICU4J component currently stores binary data files directly in the
> repository. This change replaces them with base64-encoded text files and
> converts them to binary during the build process
> Just converting a binary file to base64 d
On Fri, 27 Jun 2025 22:46:40 GMT, Xueming Shen wrote:
> [...] more in line with how resizing is handled in string builder
Looks like `StringBuilder` eventually calls
`ArraysSupport.newLength(int,int.int)`. This is probably worth checking out.
-
PR Review Comment: https://git.openj
On Fri, 27 Jun 2025 20:45:14 GMT, Naoto Sato wrote:
> The ICU4J component currently stores binary data files directly in the
> repository. This change replaces them with base64-encoded text files and
> converts them to binary during the build process
What is the point of this change? If the fi
On 27/06/2025 10:11 pm, Pavel Rappo wrote:
So, Object.wait() guarantees to throw InterruptedException if the
interrupt status is set upon entrance, yes? Could this be added to
javadoc?
It is already there:
If the current thread is interrupted by any thread *before* or while it
is waiting, the
On Fri, 27 Jun 2025 17:32:25 GMT, Brian Burkhalter wrote:
>> Replaces the implementation `readAllCharsAsString().lines().toList()` with
>> reading into a temporary `char` array which is then processed to detect line
>> terminators and copy non-terminating characters into strings which are added
On Thu, 26 Jun 2025 16:36:40 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](htt
On Thu, 26 Jun 2025 16:36:40 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](htt
On Fri, 27 Jun 2025 11:22:51 GMT, Daniel Jeliński wrote:
>> Daniel Fuchs has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 525 commits:
>>
>> - merge latest changes from master branch
>> - http3: run H3StreamLimitReachedTest.java
On Fri, 27 Jun 2025 07:51:54 GMT, Henry Jen wrote:
>> Create a jar directly from the memory instead of real file, this should
>> reduce the I/O overhead which likely the reason for the time out.
>> The issue is not reproducible locally, and fails intermittently, so we
>> simply trying to reduce
On Thu, 26 Jun 2025 16:36:40 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](htt
On Thu, 26 Jun 2025 16:36:40 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](htt
On Thu, 26 Jun 2025 20:56:39 GMT, Alisen Chung wrote:
>> This issue is responsible for updating the translations of all the
>> localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional
> commit since the las
On 27/06/2025 5:58 pm, Pavel Rappo wrote:
David,
As you correctly identified, the edge case that I mentioned is this:
concurrent interrupt and notify [^1]. It has nothing to do with
spurious wake-ups or virtual threads. In fact, I've seen that with
virtual threads Object.wait behaves exactly the
So, Object.wait() guarantees to throw InterruptedException if the
interrupt status is set upon entrance, yes? Could this be added to
javadoc?
On Fri, Jun 27, 2025 at 12:59 PM David Holmes wrote:
>
> On 27/06/2025 5:58 pm, Pavel Rappo wrote:
> > David,
> >
> > As you correctly identified, the edge
On Wed, 23 Apr 2025 06:16:14 GMT, Julian Waters wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove the got local
>
> Stay open
Hello @TheShermanTanker, I see that this PR is marked as ready for integration
s
On Fri, 27 Jun 2025 13:20:35 GMT, Jaikiran Pai wrote:
> Can I please get a review of this doc-only change which proposes to clarify
> the current implementation of the `java.util.Properties.list(...)` methods?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8360575, the current
> implement
> Can I please get a review of this doc-only change which proposes to clarify
> the current implementation of the `java.util.Properties.list(...)` methods?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8360575, the current
> implementation trims each value to a size of 37 when printing out
On Fri, 27 Jun 2025 13:41:11 GMT, Alan Bateman wrote:
> Are you sure you want to describe the format, even in an implNote? Although
> the string representation probably hasn't changed in 25+ years, it's not
> something that anything should become dependent on.
I wasn't too sure how much detail
On 28/06/2025 4:03 am, Pavel Rappo wrote:
David,
Having re-read your replies multiple times, I think I now understand
it. It finally clicked after I read your "once notified it is no
longer waiting" for the Nth time. Indeed, even if a thread has not yet
restored its synchronization claims, it's
> 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
On Fri, 27 Jun 2025 14:03:59 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which proposes to clarify
>> the current implementation of the `java.util.Properties.list(...)` methods?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8360575, the current
>> impl
On Sun, 18 May 2025 12:48:07 GMT, Shaojin Wen wrote:
> Through JVM Option +PrintInlining, we found that String has a constructor
> codeSize of 852, which is too large. This caused failed to inline.
>
> The following is the output information of PrintInlining:
>
> @ 9 java.lan
On Thu, 26 Jun 2025 16:36:40 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](htt
Scoped values cannot be used early in the JDK boot process because of some
dependencies on System.getProperty(). This repen dency should be removed in a
way that allows scoped values to be created (but not necessarily bound) at any
stage during boot.
Also, Scoped Value's constructor has a synch
On Fri, 27 Jun 2025 14:03:59 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which proposes to clarify
>> the current implementation of the `java.util.Properties.list(...)` methods?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8360575, the current
>> impl
On Fri, 27 Jun 2025 14:33:30 GMT, Andy Goryachev wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Alan's review - limit the details in implNote
>
> src/java.base/share/classes/java/util/Properties.java line 1221:
>
> Can I please get a review of this doc-only change which proposes to clarify
> the current implementation of the `java.util.Properties.list(...)` methods?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8360575, the current
> implementation trims each value to a size of 37 when printing out
David,
Having re-read your replies multiple times, I think I now understand
it. It finally clicked after I read your "once notified it is no
longer waiting" for the Nth time. Indeed, even if a thread has not yet
restored its synchronization claims, it's no longer waiting. I
suppose, the same appli
On Fri, 27 Jun 2025 16:02:45 GMT, Jaikiran Pai wrote:
>> Improve the documentation of Process use of system resources.
>>
>> Describe the implementation closing streams when no longer referenced.
>> Clarify the interactions between inputStream and inputReader and errorStream
>> and errorReader.
> Replaces the implementation `readAllCharsAsString().lines().toList()` with
> reading into a temporary `char` array which is then processed to detect line
> terminators and copy non-terminating characters into strings which are added
> to the list.
Brian Burkhalter has updated the pull request
On Fri, 27 Jun 2025 19:21:19 GMT, Roger Riggs wrote:
> More directly, use limit instead of term in the computation of length.
Good point. So changed in 3e5e498.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2172749427
On Fri, 27 Jun 2025 18:27:15 GMT, Alisen Chung wrote:
> 8359761: JDK 25 RDP1 L10n resource files update
This pull request has now been integrated.
Changeset: 12ffb0c1
Author:Alisen Chung
URL:
https://git.openjdk.org/jdk/commit/12ffb0c131c5100dc23549b9b7216625bc0dab9e
Stats: 1196
On Thu, 26 Jun 2025 17:43:21 GMT, Daniel Fuchs wrote:
>> Daniel Fuchs has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 525 commits:
>>
>> - merge latest changes from master branch
>> - http3: run H3StreamLimitReachedTest.java wit
On Wed, 2 Apr 2025 14:54:35 GMT, Magnus Ihse Bursie wrote:
> In the static JDK image, a single humongous java executable is generated, and
> no other launcher, such as javac. This makes it impossible to run our jtreg
> tests, which assume these are present.
>
> The solution is fortunately simp
On Wed, 2 Apr 2025 14:54:35 GMT, Magnus Ihse Bursie wrote:
> In the static JDK image, a single humongous java executable is generated, and
> no other launcher, such as javac. This makes it impossible to run our jtreg
> tests, which assume these are present.
>
> The solution is fortunately simp
On Thu, 3 Apr 2025 14:09:58 GMT, Alan Bateman wrote:
> As regards the shim when I wonder if it should use CreateProcessW but maybe
> it doesn't matter for the test environments where they will run.
I must admit that I am not very well versed in Windows programming. What is the
difference? I th
> In the static JDK image, a single humongous java executable is generated, and
> no other launcher, such as javac. This makes it impossible to run our jtreg
> tests, which assume these are present.
>
> The solution is fortunately simply: we just need to add a bunch of trivial
> launchers, whic
On Thu, 3 Apr 2025 14:24:18 GMT, Magnus Ihse Bursie wrote:
> So while we continue to hammer out how to improve this, I think it is
> important to be able to test static builds in mainline, or they will break.
Agree with @magicus on the importance of being able to test static builds in
mainlin
On Wed, 18 Jun 2025 20:16:18 GMT, Roger Riggs wrote:
> Improve the documentation of Process use of system resources.
>
> Describe the implementation closing streams when no longer referenced.
> Clarify the interactions between inputStream and inputReader and errorStream
> and errorReader.
> Add
On Thu, 3 Apr 2025 14:09:58 GMT, Alan Bateman wrote:
> Right now, the static-jdk image is a bit strange in that it's a modular
> run-time image but with all native code compiled into bin/java. In time we
> hope that jlink will be able to create a static image where everything is in
> the singl
> In the static JDK image, a single humongous java executable is generated, and
> no other launcher, such as javac. This makes it impossible to run our jtreg
> tests, which assume these are present.
>
> The solution is fortunately simply: we just need to add a bunch of trivial
> launchers, whic
On Fri, 27 Jun 2025 16:12:53 GMT, Jaikiran Pai wrote:
>> src/java.base/share/classes/java/lang/Process.java line 202:
>>
>>> 200: *
>>> 201: * @apiNote
>>> 202: * Avoid using both {@link #getInputStream} and {@link
>>> #inputReader(Charset)}.
>>
>> The reworded sentence I think
On Fri, 27 Jun 2025 16:09:02 GMT, Jaikiran Pai wrote:
>> Improve the documentation of Process use of system resources.
>>
>> Describe the implementation closing streams when no longer referenced.
>> Clarify the interactions between inputStream and inputReader and errorStream
>> and errorReader.
On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung wrote:
> This issue is responsible for updating the translations of all the
> localize(able) resources in the JDK since the previous L10n drop.
This pull request has now been integrated.
Changeset: da7080ff
Author:Alisen Chung
URL:
htt
On Wed, 18 Jun 2025 20:16:18 GMT, Roger Riggs wrote:
> Improve the documentation of Process use of system resources.
>
> Describe the implementation closing streams when no longer referenced.
> Clarify the interactions between inputStream and inputReader and errorStream
> and errorReader.
> Add
On Fri, 27 Jun 2025 16:15:57 GMT, Magnus Ihse Bursie wrote:
>> In the static JDK image, a single humongous java executable is generated,
>> and no other launcher, such as javac. This makes it impossible to run our
>> jtreg tests, which assume these are present.
>>
>> The solution is fortunatel
On Wed, 18 Jun 2025 20:16:18 GMT, Roger Riggs wrote:
> Improve the documentation of Process use of system resources.
>
> Describe the implementation closing streams when no longer referenced.
> Clarify the interactions between inputStream and inputReader and errorStream
> and errorReader.
> Add
> Replaces the implementation `readAllCharsAsString().lines().toList()` with
> reading into a temporary `char` array which is then processed to detect line
> terminators and copy non-terminating characters into strings which are added
> to the list.
Brian Burkhalter has updated the pull request
On Fri, 27 Jun 2025 01:03:30 GMT, Kim Barrett wrote:
>> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
>> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
>> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
>>
8359761: JDK 25 RDP1 L10n resource files update
-
Commit messages:
- Backport da7080fffb2389465dc9afca6d02e9085fe15302
Changes: https://git.openjdk.org/jdk/pull/26026/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26026&range=00
Issue: https://bugs.openjdk.org/browse/JDK
On Fri, 27 Jun 2025 09:48:20 GMT, Kieran Farrell wrote:
>> With the recent approval of UUIDv7
>> (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new
>> static method UUID.timestampUUID() which constructs and returns a UUID in
>> support of the new time generated UUID version
On Fri, 27 Jun 2025 15:36:29 GMT, Roger Riggs wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8358533: Test change accidentally omitted from previous commit
>
> src/java.base/share/classes/java/io/Reader.java l
On Fri, 27 Jun 2025 18:27:15 GMT, Alisen Chung wrote:
> 8359761: JDK 25 RDP1 L10n resource files update
Marked as reviewed by jlu (Committer).
-
PR Review: https://git.openjdk.org/jdk/pull/26026#pullrequestreview-2967612181
On Fri, 27 Jun 2025 17:32:25 GMT, Brian Burkhalter wrote:
>> Replaces the implementation `readAllCharsAsString().lines().toList()` with
>> reading into a temporary `char` array which is then processed to detect line
>> terminators and copy non-terminating characters into strings which are added
On Fri, 27 Jun 2025 18:52:14 GMT, Brian Burkhalter wrote:
>> src/java.base/share/classes/java/io/Reader.java line 494:
>>
>>> 492: skipLF = isCR;
>>> 493: } else { // no line terminator
>>> 494: int len = term - pos;
>>
>> I think term ==
On Fri, 27 Jun 2025 18:44:55 GMT, Roger Riggs wrote:
>> Brian Burkhalter has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - 8358533: Use a boolean instead of fragPos != -1
>> - 8358533: Immediately skip LF right after CR
>
> src/java.bas
On Fri, 27 Jun 2025 18:27:15 GMT, Alisen Chung wrote:
> 8359761: JDK 25 RDP1 L10n resource files update
Marked as reviewed by aivanov (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/26026#pullrequestreview-2967634176
> Improve the documentation of Process use of system resources.
>
> Describe the implementation closing streams when no longer referenced.
> Clarify the interactions between inputStream and inputReader and errorStream
> and errorReader.
> Add advice and example using try-with-resources to open an
On Thu, 22 May 2025 00:57:06 GMT, Shaojin Wen wrote:
>> The byte[] allocated in Integer/Long.toString is fully filled, so we can use
>> StringConcatHelper::newArray to create byte[] to improve performance.
>
> Shaojin Wen has updated the pull request with a new target base due to a
> merge or a
On Fri, 27 Jun 2025 18:54:20 GMT, Brian Burkhalter wrote:
>> Yes, `term == limit`. The "no line terminator" means none was encountered
>> before the buffer's end was reached.
>
> Maybe it should be something like:
>
> // no line terminator before end of buffer
More directly, use limit instead
> With the recent approval of UUIDv7
> (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static
> method UUID.timestampUUID() which constructs and returns a UUID in support of
> the new time generated UUID version.
>
> The specification requires embedding the current times
On Thu, 26 Jun 2025 16:36:40 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](htt
On Thu, 26 Jun 2025 16:36:40 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](htt
Can I please get a review of this doc-only change which proposes to clarify the
current implementation of the `java.util.Properties.list(...)` methods?
As noted in https://bugs.openjdk.org/browse/JDK-8360575, the current
implementation trims each value to a size of 37 when printing out the value
On Fri, 27 Jun 2025 11:37:00 GMT, Daniel Jeliński wrote:
>> Daniel Fuchs has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 525 commits:
>>
>> - merge latest changes from master branch
>> - http3: run H3StreamLimitReachedTest.java
On Thu, 1 May 2025 00:01:08 GMT, Chen Liang wrote:
> As another step toward the removal of the old generics infrastructure, I
> propose to remove the usages of generic parsing utilities and use the
> facilities provided by BytecodeDescriptor, already used by
> MethodType.fromDescriptorString.
> Replaces the implementation `readAllCharsAsString().lines().toList()` with
> reading into a temporary `char` array which is then processed to detect line
> terminators and copy non-terminating characters into strings which are added
> to the list.
Brian Burkhalter has updated the pull request
On Thu, 26 Jun 2025 16:36:40 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](htt
On Fri, 27 Jun 2025 14:45:19 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which proposes to clarify
>> the current implementation of the `java.util.Properties.list(...)` methods?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8360575, the current
>> impl
On Thu, 26 Jun 2025 16:36:40 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](htt
On Fri, 27 Jun 2025 14:32:11 GMT, Andrew Haley wrote:
> Scoped values cannot be used early in the JDK boot process because of some
> dependencies on System.getProperty(). This dependency should be removed in a
> way that allows scoped values to be created (but not necessarily bound) at
> any s
On Fri, 27 Jun 2025 14:45:19 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which proposes to clarify
>> the current implementation of the `java.util.Properties.list(...)` methods?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8360575, the current
>> impl
On Fri, 27 Jun 2025 15:27:45 GMT, Roger Riggs wrote:
> You'll need a CSR since you're changing spec text.
isn't this PR a mere clarification, as opposed to the spec change? Or any
change is a spec change in the JDK project? (openjfx allows for minor javadoc
corrections without a CSR)
--
On Fri, 27 Jun 2025 15:12:57 GMT, Chen Liang wrote:
> I looked at the existing code: the reason ScopedValue creation requires
> getProperty in Cache is that `generateKey` uses `Cache.primarySlot(x)` and
> `Cache.secondarySlot(x)`. Why did you choose to factor out `getProperty` into
> a new cla
On Fri, 27 Jun 2025 15:31:04 GMT, Andy Goryachev wrote:
> isn't this PR a mere clarification, as opposed to the spec change? Or any
> change is a spec change in the JDK project? (openjfx allows for minor javadoc
> corrections without a CSR)
For JDK, (nearly) all changes to the javadoc require
On Fri, 27 Jun 2025 15:03:05 GMT, Brian Burkhalter wrote:
>> Replaces the implementation `readAllCharsAsString().lines().toList()` with
>> reading into a temporary `char` array which is then processed to detect line
>> terminators and copy non-terminating characters into strings which are added
On Fri, 27 Jun 2025 14:32:11 GMT, Andrew Haley wrote:
> Scoped values cannot be used early in the JDK boot process because of some
> dependencies on System.getProperty(). This dependency should be removed in a
> way that allows scoped values to be created (but not necessarily bound) at
> any s
On Wed, 18 Jun 2025 20:16:18 GMT, Roger Riggs wrote:
> Improve the documentation of Process use of system resources.
>
> Describe the implementation closing streams when no longer referenced.
> Clarify the interactions between inputStream and inputReader and errorStream
> and errorReader.
> Add
84 matches
Mail list logo
