350588)
>
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC
> protocol based on DatagramChannel and the SunJSSE SSLContext provider.
Daniel Fuchs has updated the pull request with a new
350588)
>
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC
> protocol based on DatagramChannel and the SunJSSE SSLContext provider.
Daniel Fuchs has updated the pull request with a new
On Tue, 1 Jul 2025 15:20:07 GMT, Jaikiran Pai wrote:
>> The uniqueness comes not just from the timestamp but also from the random
>> data in the other bytes that are generated for each new UUID.
>
> Hello Roger, that's true about the uniqueness semantics. However, from what I
> understand of RF
On Tue, 1 Jul 2025 11:48:30 GMT, Jaikiran Pai wrote:
> Can I please get a review of this backport of a test-only fix?
>
> This backports the fix for https://bugs.openjdk.org/browse/JDK-8359337 into
> JDK 25. The original fix was integrated into mainline a few minutes back
> https://github.com
On Mon, 30 Jun 2025 09:34:48 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
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
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
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
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
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
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
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
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
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
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
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
On Thu, 26 Jun 2025 17:36:21 GMT, Daniel Jeliński wrote:
>> src/java.base/share/classes/jdk/internal/net/quic/QuicTLSContext.java line
>> 70:
>>
>>> 68: if (!(underlyingImpl instanceof SSLContextImpl ssci)) {
>>> 69: return false;
>>> 70: }
>>
>> Would there be a wa
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
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
350588)
>
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC
> protocol based on DatagramChannel and the SunJSSE SSLContext provider.
Daniel Fuchs has updated the pull request with a new
On Thu, 26 Jun 2025 11:04:33 GMT, Daniel Fuchs wrote:
>> Thank you Artur.
>>
>> @dfuch this conversation can be resolved too.
>
> Done
> Hi Jaikiran! Sounds good. It's likely we are going to re-work this code
> anyhow when we make QUIC engine pub
On Thu, 26 Jun 2025 13:22:28 GMT, Jaikiran Pai wrote:
>> src/java.base/share/classes/sun/security/ssl/X509Authentication.java line
>> 226:
>>
>>> 224: chc.peerSupportedAuthorities == null ? null :
>>> 225: chc.peerSupportedAuthorities.clone(),
>>>
On Thu, 26 Jun 2025 01:04:41 GMT, Jaikiran Pai wrote:
>> Hi Jaikiran! Sounds good. It's likely we are going to re-work this code
>> anyhow when we make QUIC engine public in the next iteration. We had a
>> discussion with Daniel about it today.
>
> Thank you Artur.
>
> @dfuch this conversation
On Wed, 4 Jun 2025 17:43:16 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 506 commits:
>>
>> - merge latest changes from master branch
>> - http3: update
350588)
>
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC
> protocol based on DatagramChannel and the SunJSSE SSLContext provider.
Daniel Fuchs has updated the pull request with a new
On Thu, 15 May 2025 23:59:41 GMT, Brent Christian wrote:
>> Please review this change to replace the finalizer in
>> `AbstractLdapNamingEnumeration` with Cleaner.
>>
>> (The [first PR](https://github.com/openjdk/jdk/pull/8311) for this fix
>> started some substantial discussions, leading to, a
On Fri, 6 Jun 2025 18:35:53 GMT, Phil Race wrote:
> The fix for JDK-8344235: Revisit SecurityManager usage in java.logging after
> JEP 486 and JEP 491 integration
> removed use of AppContext from java/util/logging/LogManager.java.
> That was the only place in the JDK that used
> jdk.internal.ac
350588)
>
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC
> protocol based on DatagramChannel and the SunJSSE SSLContext provider.
Daniel Fuchs has updated the pull request with a new
On Wed, 4 Jun 2025 15:46:36 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
On Fri, 16 May 2025 10:26:11 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 422 commits:
>>
>> - merge latest changes from master branch
>> - Undo
350588)
>
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC
> protocol based on DatagramChannel and the SunJSSE SSLContext provider.
Daniel Fuchs has updated the pull request with a new
On Wed, 4 Jun 2025 15:03:11 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this trivial doc-only change to the
>> `jdk.zipfs`'s documentation? This moves the `accessMode` property listing to
>> the top of the table instead of being at the bottom. With this change, the
>> text about t
On Wed, 4 Jun 2025 06:47:59 GMT, Jaikiran Pai wrote:
> Can I please get a review of this trivial doc-only change to the
> `jdk.zipfs`'s documentation? This moves the `accessMode` property listing to
> the top of the table instead of being at the bottom. With this change, the
> text about throw
On Tue, 3 Jun 2025 14:23:54 GMT, Michael McMahon wrote:
>> Hi,
>>
>> Enhanced exception messages are designed to hide sensitive information such
>> as hostnames, IP
>> addresses from exception message strings, unless the enhanced mode for the
>> specific category
>> has been explicitly enabl
x27; into 8348986-exceptions
> - doc update to java.security
> - removed jmod/Handler change
> - doc update to java.security
> - Fixed problem with j.n.HostPortRange
> - typo in suggestions and other issues
> - Merge branch 'master' into 8348986-exceptions
> -
On Thu, 29 May 2025 14:35:11 GMT, Michael McMahon wrote:
>> Hi,
>>
>> Enhanced exception messages are designed to hide sensitive information such
>> as hostnames, IP
>> addresses from exception message strings, unless the enhanced mode for the
>> specific category
>> has been explicitly enab
On Mon, 26 May 2025 08:16:03 GMT, Matthias Baesken wrote:
>> On a 'german' Ubuntu 24 (LANG="de_DE.UTF-8") the jtreg test
>> java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest
>> fails with
>>
>>
>> FEIN: hi now!
>> java.lang.RuntimeException: System.err does not contai
On Mon, 19 May 2025 12:24:28 GMT, Jaikiran Pai wrote:
>> Hello David, I had another look at this code and after going through it, it
>> looked like `readOnly` field can in fact be made `final` because of the
>> refactoring changes that you did in this PR. I checked out your latest PR
>> locall
On Mon, 26 May 2025 16:16:44 GMT, Jaikiran Pai wrote:
> Additionally, the addRequest(), close() and cancel() methods of this
> LdapRequet get called by a single thread managed by the Connection class, so
> there isn't expected to be concurrent calls across these methods.
I am not seeing that
On Mon, 26 May 2025 12:28:16 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to address the issue
> noted in https://bugs.openjdk.org/browse/JDK-8357708?
>
> As noted in the issue, the current code in
> `com.sun.jndi.ldap.Connection.readReply()` is susceptibl
On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon wrote:
>> Hi,
>>
>> Enhanced exception messages are designed to hide sensitive information such
>> as hostnames, IP
>> addresses from exception message strings, unless the enhanced mode for the
>> specific category
>> has been explicitly enab
On Mon, 26 May 2025 08:16:03 GMT, Matthias Baesken wrote:
>> On a 'german' Ubuntu 24 (LANG="de_DE.UTF-8") the jtreg test
>> java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest
>> fails with
>>
>>
>> FEIN: hi now!
>> java.lang.RuntimeException: System.err does not contai
On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla wrote:
> Please review this patch to fix some `javadoc` bugs in `java.base`.
> Certain `@link` tags used to refer to private fields instead of public APIs.
>
> A couple of `@see` tags in the [serialization
> page](https://download.java.net/java/ea
On Fri, 16 May 2025 11:42:08 GMT, Michael McMahon wrote:
>> Hi,
>>
>> Enhanced exception messages are designed to hide sensitive information such
>> as hostnames, IP
>> addresses from exception message strings, unless the enhanced mode for the
>> specific category
>> has been explicitly enab
On Fri, 9 May 2025 14:39:53 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the
>> HTTP Client API](https://openjdk.org/jeps/517).
>>
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517
On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie wrote:
> A handful of html and xml files in the JDK source tree claims to have
> encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
>
> While perhaps technically correct, this is misleading, and goes contrary to
> the eff
350588)
>
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC
> protocol based on DatagramChannel and the SunJSSE SSLContext provider.
Daniel Fuchs has updated the pull request with a new
On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth wrote:
> The whole idea of running with a timeout factor of `0.7` is to remove
> intermittent failures. (I had it close to 0.5 or maybe less to begin with
> until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on
> socket timeout
On Thu, 8 May 2025 17:41:02 GMT, Daniel Fuchs wrote:
> Thank you. I have imported your PR locally and running some HTTP client tests
> in the CI.
> Tests have not finished running - but I already see one intermittent failure:
> `java/net/httpclient/RedirectTimeoutTest.java` i
On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote:
> This change tries to add timeout to individual testcases so that I am able to
> run them with a timeout factor of 1 in the future (JDK-8260555).
>
> The first commit changes the timeout factor to 0.7, so that I can run tests
> and test the
On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote:
> This change tries to add timeout to individual testcases so that I am able to
> run them with a timeout factor of 1 in the future (JDK-8260555).
>
> The first commit changes the timeout factor to 0.7, so that I can run tests
> and test the
On Tue, 6 May 2025 14:40:46 GMT, Per Minborg wrote:
>> This sketch shows how "Stable Updaters" can be used to create stable
>> computations of `@Stable` fields. Only one updater is needed per class,
>> similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg has updated the pull request incremen
On Thu, 1 May 2025 17:26:48 GMT, Joe Darcy wrote:
>> Note, the timeout factor also adjusts the jtreg timeout for the entire test.
>> The adjustTimeout() method allows internal test timeouts to scale along with
>> the jtreg timeout.
>
>> Hi Joe, yes `adjustTimeout` will scale based on the jtreg
rg/browse/JDK-8350588)
>
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC
> protocol based on DatagramChannel and the SunJSSE SSLContext provider.
Daniel Fuchs has updated the pull reques
On Wed, 30 Apr 2025 10:19:54 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for
>> the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>>
>> The CSR can be viewed at [JDK-83
rg/browse/JDK-8350588)
>
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC
> protocol based on DatagramChannel and the SunJSSE SSLContext provider.
Daniel Fuchs has updated the pull reques
On Sat, 26 Apr 2025 17:07:33 GMT, Markus KARG wrote:
>> This Pull Request proposes an implementation for
>> [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new
>> method `public void getChars(int srcBegin, int srcEnd, char[] dst, int
>> dstBegin)` to the `CharSequence` i
rg/browse/JDK-8350588)
>
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC
> protocol based on DatagramChannel and the SunJSSE SSLContext provider.
Daniel Fuchs has updated the pull reques
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 18:48:06 GMT, Chen Liang wrote:
>> PushId is an HTTP/3 concept. It would be strange to have a generic method
>> (sendAsync) that you could call with any requests, but with a parameter that
>> could only be used for HTTP/3. We don't have pushIds for HTTP/2. I don't
>> think
On Fri, 18 Apr 2025 18:49:19 GMT, Chen Liang wrote:
>> Hi,
>>
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for
>> the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>>
>> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client
On Mon, 21 Apr 2025 19:05:54 GMT, Joe Darcy wrote:
>> David Beaumont has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Removing test from the problem list.
>
> test/jdk/java/util/logging/LoggingDeadlock5.java line 127:
>
>> 125: /
Hi,
Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for
the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client
API](https://bugs.openjdk.org/browse/JDK-8350588)
This JEP proposes to
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 Wed, 16 Apr 2025 12:12:14 GMT, David Beaumont wrote:
> Increasing timeout for deadlock detection and adjusting for the timeout
> factor in higher tiers.
Hard to tell whether 1s would be enough. I'd be tempted to bump that up.
You should also take the test out of the problem list.
--
On Wed, 16 Apr 2025 11:20:36 GMT, Jaikiran Pai wrote:
> This brings in the CPU25_04 changes into the master branch.
LGTM
-
Marked as reviewed by dfuchs (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/24683#pullrequestreview-2772164693
On Tue, 15 Apr 2025 14:35:28 GMT, Michael McMahon wrote:
>> Hi,
>>
>> Enhanced exception messages are designed to hide sensitive information such
>> as hostnames, IP
>> addresses from exception message strings, unless the enhanced mode for the
>> specific category
>> has been explicitly enab
On Mon, 14 Apr 2025 10:56:45 GMT, David Beaumont wrote:
> Add null pointer guard in test formatter (since it can be called with a log
> record without parameters).
Trivial fix. Looks like the right thing to do.
-
Marked as reviewed by dfuchs (Reviewer).
PR Review: https://git.ope
On Thu, 10 Apr 2025 21:26:21 GMT, Michael McMahon wrote:
>> Hi,
>>
>> Enhanced exception messages are designed to hide sensitive information such
>> as hostnames, IP
>> addresses from exception message strings, unless the enhanced mode for the
>> specific category
>> has been explicitly enab
On Tue, 8 Apr 2025 11:03:39 GMT, David Beaumont wrote:
>> 8353683: 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
On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan wrote:
> Please review this change to terminally deprecate the following security
> related permission classes: `java.security.AllPermission`,
> `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`,
> `javax.security.auth.AuthPermissi
Hi David,
Are there other subclasses of Permission that this framework uses?
More specifically - would it be fine to deprecate NetPermission,
URLPermission and SocketPermission classes?
best regards,
-- daniel
On 04/04/2025 15:51, David M. Lloyd wrote:
Can you elaborate or give an example/poi
On Fri, 4 Apr 2025 12:37:32 GMT, Roger Riggs wrote:
> Now that the Security Manager is permanently disabled, the following
> permission classes in the core libraries area can be deprecated for removal
> as they are no longer useful: FilePermission, LinkPermission,
> LoggingPermission, Property
On Wed, 2 Apr 2025 21:59:32 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
On Wed, 2 Apr 2025 13:39:22 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
On Thu, 13 Mar 2025 01:21:54 GMT, Archie Cobbs wrote:
> This PR fixes minor Javadoc typos in a few `java.base` classes. Extra curly
> braces have been sneaking in.
LGTM
-
PR Review: https://git.openjdk.org/jdk/pull/24022#pullrequestreview-2681298904
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
On Fri, 28 Feb 2025 14:23:49 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 affe
On Thu, 27 Feb 2025 17:15:56 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 affe
On Fri, 28 Feb 2025 00:59:22 GMT, Stuart Marks wrote:
>> src/java.logging/share/classes/java/util/logging/SocketHandler.java line 178:
>>
>>> 176: // JDK-8349206: Do NOT synchronize around the parent's
>>> publish() method.
>>> 177: super.publish(record);
>>> 178: flush(
On Mon, 24 Feb 2025 19:24:42 GMT, Roger Riggs wrote:
>> Yep, I think overriding methods are considered usages of API. Implementation
>> applies to the exact method implementation.
>
> There are elements of both implNote and ApiNote, maybe there is clarity in
> separating the descriptions into t
On Mon, 24 Feb 2025 15:20:13 GMT, Roger Riggs wrote:
>> I've asked on the CSR if this should be @implNote or @implSpec.
>
> Those read more like an @ApiNote, advice on how to use the API.
@RogerRiggs - Is overriding a method and calling `super` considered a use of
the API? Because these notes a
On Mon, 24 Feb 2025 11:58:11 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 affe
On Fri, 21 Feb 2025 17:04:11 GMT, Brian Burkhalter wrote:
>> src/java.base/unix/classes/java/io/UnixFileSystem.java line 37:
>>
>>> 35:
>>> 36: private String getPathForSysCalls(String path) {
>>> 37: return path.isEmpty() ? getCWD().getPath() : path;
>>
>> The Windows implementati
On Thu, 20 Feb 2025 22:20:04 GMT, Brian Burkhalter wrote:
>> Update the specification of `java.io.File.exists()` to match its behavior,
>> which seems correct in the context of how the empty abstract pathname is
>> documented elsewhere in the class.
>
> Brian Burkhalter has updated the pull req
On Thu, 20 Feb 2025 17:38:21 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 affe
On Fri, 14 Feb 2025 16:32:08 GMT, David Beaumont wrote:
>> src/java.logging/share/classes/java/util/logging/FileHandler.java line 193:
>>
>>> 191: out.write(b);
>>> 192: written++;
>>> 193: flushOrRotateIfFull();
>>
>> I don't think that's correct. You don't
On Fri, 14 Feb 2025 15:18:56 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 affe
On Wed, 12 Feb 2025 19:41:44 GMT, Jason Mehrens 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
On Thu, 6 Feb 2025 12:07:57 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 affected me
On Thu, 6 Feb 2025 12:07:57 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 affected me
On Thu, 6 Feb 2025 12:07:57 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 affected me
On Thu, 23 Jan 2025 15:23:37 GMT, Kevin Walls wrote:
> java.util.logging.LoggingMXBean and
> java.util.logging.LogManager::getLoggingMXBean are deprecated since
> JDK-8139982 in JDK 9.
>
> These deprecations should be uprated to state they are for future removal.
>
> java.util.logging.Logging
On Thu, 23 Jan 2025 15:23:37 GMT, Kevin Walls wrote:
> java.util.logging.LoggingMXBean and
> java.util.logging.LogManager::getLoggingMXBean are deprecated since
> JDK-8139982 in JDK 9.
>
> These deprecations should be uprated to state they are for future removal.
>
> java.util.logging.Logging
On Tue, 4 Feb 2025 14:26:23 GMT, Volkan Yazici wrote:
>> Adds `test.lib.Utils::createTempFileOfSize` to generate
>> `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory
>> contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file
>> tracked by git:
>>
>>
On Tue, 4 Feb 2025 12:04:47 GMT, Volkan Yazici wrote:
>> Adds `test.lib.Utils::createTempFileOfSize` to generate
>> `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory
>> contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file
>> tracked by git:
>>
>>
On Mon, 3 Feb 2025 19:26:03 GMT, Volkan Yazici wrote:
>> Adds `test.lib.Utils::createTempFileOfSize` to generate
>> `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory
>> contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file
>> tracked by git:
>>
>>
On Thu, 23 Jan 2025 10:38:50 GMT, serhiysachkov wrote:
> Add additional diagnostics to macOS failure handler to assist with diagnosing
> MCast test failures
Marked as reviewed by dfuchs (Reviewer).
Looks good to me. Good to have these additional diagnostics.
-
PR Review: https://
On Wed, 22 Jan 2025 11:22:49 GMT, Jaikiran Pai wrote:
> This brings in CPU25_01 changes into master branch.
Marked as reviewed by dfuchs (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/23231#pullrequestreview-2566935776
On Wed, 22 Jan 2025 11:22:53 GMT, Jaikiran Pai wrote:
> This brings in CPU25_01 changes into jdk24 branch.
Marked as reviewed by dfuchs (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/23232#pullrequestreview-2566937917
1 - 100 of 492 matches
Mail list logo
