On Fri, 11 Apr 2025 09:00:05 GMT, Daniel Fuchs wrote:
> Please find her a patch that deprecate networking permission classes for
> removal. The method `URL::getPermission` now serves little purpose and is
> also deprecated. That method was overridden in subclasses and specified to
On Fri, 9 May 2025 19:19:03 GMT, Daniel Fuchs wrote:
>> src/java.base/share/classes/java/net/HttpURLConnection.java line 615:
>>
>>> 613: */
>>> 614: @Deprecated(since = "25", forRemoval = true)
>>> 615: @SuppressWarnings("remov
On Fri, 9 May 2025 19:18:58 GMT, Daniel Fuchs wrote:
>> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>> line 214:
>>
>>> 212: */
>>> 213: @Override
>>> 214: @Deprecated(since = "25", forRemoval
On Fri, 9 May 2025 16:42:31 GMT, Sean Mullan wrote:
>> Daniel Fuchs 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 five addi
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
> Please find her a patch that deprecate networking permission classes for
> removal. The method `URL::getPermission` now serves little purpose and is
> also deprecated. That method was overridden in subclasses and specified to
> return some of the deprecated permissions.
Dani
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 16:10:18 GMT, Daniel Fuchs wrote:
>> Please find her a patch that deprecate networking permission classes for
>> removal. The method `URL::getPermission` now serves little purpose and is
>> also deprecated. That method was overridden in subclasse
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
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 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
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 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 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 Fri, 11 Apr 2025 13:47:10 GMT, Michael McMahon wrote:
>> Daniel Fuchs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Missing white spaces
>
> src/java.base/share/classes/java/security/CodeS
> Please find her a patch that deprecate networking permission classes for
> removal. The method `URL::getPermission` now serves little purpose and is
> also deprecated. That method was overridden in subclasses and specified to
> return some of the deprecated permissions.
Dani
On Fri, 11 Apr 2025 11:47:21 GMT, Daniel Fuchs wrote:
>> I think we should at least consider deprecating URLConnection.getPermission
>> and HttpURLConnection.getPermission for removal, only because I don't
>> immediately see the advantage of doing it in two steps for the
On Fri, 11 Apr 2025 12:31:04 GMT, Daniel Fuchs wrote:
> The GHA failure (Windows) appears to be related.
Should be fixed now
-
PR Comment: https://git.openjdk.org/jdk/pull/24592#issuecomment-2796995066
On Fri, 11 Apr 2025 12:01:52 GMT, Daniel Jeliński wrote:
> The GHA failure (Windows) appears to be related.
Yes - I missed one windows specific file in my original patch. I have a test
running in the CI and I am waiting for it to pass before updating the PR.
-
PR Comment: https://
On Fri, 11 Apr 2025 11:34:36 GMT, Alan Bateman wrote:
>> Possibly. @AlanBateman may have some thoughts on this.
>
> I think we should at least consider deprecating URLConnection.getPermission
> and HttpURLConnection.getPermission for removal, only because I don't
> immediately see the advantage
On Fri, 11 Apr 2025 11:10:10 GMT, Daniel Jeliński wrote:
>> src/java.base/share/classes/java/security/CodeSource.java line 468:
>>
>>> 466: }
>>> 467: @SuppressWarnings("removal")
>>> 468: var result = this.sp.implies(that.sp);
>>
>> Will we need
On Fri, 11 Apr 2025 10:45:20 GMT, Daniel Jeliński wrote:
>> Daniel Fuchs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Missing white spaces
>
> src/java.base/share/classes/java/net/HttpURLConne
> Please find her a patch that deprecate networking permission classes for
> removal. The method `URL::getPermission` now serves little purpose and is
> also deprecated. That method was overridden in subclasses and specified to
> return some of the deprecated permissions.
Dani
On Fri, 11 Apr 2025 09:00:05 GMT, Daniel Fuchs wrote:
> Please find her a patch that deprecate networking permission classes for
> removal. The method `URL::getPermission` now serves little purpose and is
> also deprecated. That method was overridden in subclasses and specified to
Please find her a patch that deprecate networking permission classes for
removal. The method `URL::getPermission` now serves little purpose and is also
deprecated. That method was overridden in subclasses and specified to return
some of the deprecated permissions.
-
Commit message
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 Thu, 6 Feb 2025 19:47:54 GMT, Artur Barashev wrote:
>> I still think that `Convert to the default ALPN encoding` comment is less
>> confusing, we are just passing the string in the encoding that the library
>> expects. Basically your comment assumes reader's familiarity with the RFC.
>
> `Co
request incrementally with one
> additional commit since the last revision:
>
> Apply suggestions from cr
>
> Co-authored-by: Daniel Fuchs <67001856+df...@users.noreply.github.com>
Marked as reviewed by dfuchs (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/23469#pullrequestreview-2596826422
On Wed, 5 Feb 2025 17:39:42 GMT, Mikhail Yankelevich wrote:
> * fully automated the test
> * removed the race condition
> * client on a thread and server on a thread options are now run together
> automatically
And implementing the suggested changes would be good...
-
Changes requ
On Wed, 5 Feb 2025 17:39:42 GMT, Mikhail Yankelevich wrote:
> * fully automated the test
> * removed the race condition
> * client on a thread and server on a thread options are now run together
> automatically
The new logic looks good to me. Please wait for a review from someone from
security
On Tue, 4 Feb 2025 19:42:24 GMT, Bradford Wetmore wrote:
>> Update and clarify the sample code.
>>
>> Docs only, no additional testing other than verifying javadoc is correctly
>> output.
>
> Bradford Wetmore has updated the pull request incrementally with one
> additional commit since the las
On Wed, 5 Feb 2025 17:42:11 GMT, Bradford Wetmore wrote:
>> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 661:
>>
>>> 659: * // Encode 3 Meetei Mayek letters (HUK, UN, I) using Unicode
>>> Escapes
>>> 660: * // 0xabcd->0xabcf, 2 Unicode bytes/letter.
>>
On Tue, 4 Feb 2025 19:42:24 GMT, Bradford Wetmore wrote:
>> Update and clarify the sample code.
>>
>> Docs only, no additional testing other than verifying javadoc is correctly
>> output.
>
> Bradford Wetmore has updated the pull request incrementally with one
> additional commit since the las
On Wed, 5 Feb 2025 11:59:49 GMT, Daniel Fuchs wrote:
>> Bradford Wetmore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Codereview Comments
>
> src/java.base/share/classes/javax/net/ssl/SSLParam
On Fri, 31 Jan 2025 01:45:47 GMT, Bradford Wetmore wrote:
> Update and clarify the sample code.
>
> Docs only, no additional testing other than verifying javadoc is correctly
> output.
src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 668:
> 666: * String encodedHukUn
On Mon, 13 Jan 2025 16:07:45 GMT, Daniel Fuchs wrote:
> There are a few places in the HttpClient code base where we close the
> connection when some error/exception happens. This can some time trigger a
> race condition where closing the connection in turns causes a "connec
On Tue, 14 Jan 2025 09:52:59 GMT, Jaikiran Pai wrote:
>> Daniel Fuchs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review feedback from @japai
>
> src/java.net.http/share/classes/jdk/internal/net/http/
ption in the underlying
> connection before closing it, and that this is the exception that gets
> subsequently reported.
>
> Some minor drive by test fixes. No new regression test.
Daniel Fuchs has updated the pull request incrementally with one additional
commit since
There are a few places in the HttpClient code base where we close the
connection when some error/exception happens. This can some time trigger a race
condition where closing the connection in turns causes a "connection closed
locally" exception to get reported instead of the original exception.
On Mon, 13 Jan 2025 13:36:53 GMT, Sean Mullan wrote:
> Some additional removal of calls to SM APIs from security library tests. One
> test is removed since it is no longer an issue.
Changes to SimpleSSLContext LGTM. Nice simplification!
-
PR Review: https://git.openjdk.org/jdk/pul
On Wed, 8 Jan 2025 19:41:42 GMT, Hannes Wallnöfer wrote:
> Please review a doc-only change to add missing `@serial` javadoc tags in
> module `java.base`. This is a sub-task of [JDK-8286931] to allow us to
> re-enable the javadoc `-serialwarn` option in the JDK doc build, which has
> been disab
On Wed, 18 Dec 2024 17:01:30 GMT, Roger Riggs wrote:
>> SM Cleanup of common test library test/lib/...:
>>
>> Remove unnecessary catches of SecurityException
>> Remove AccessController and doPrivileged from SimpleSSLContext and
>> ProcessTools.
>
> Roger Riggs has updated the pull request incre
On Wed, 18 Dec 2024 15:00:13 GMT, Roger Riggs wrote:
> SM Cleanup of common test library test/lib/...:
>
> Remove unnecessary catches of SecurityException
> Remove AccessController and doPrivileged from SimpleSSLContext and
> ProcessTools.
LGTM
test/lib/jdk/test/lib/net/SimpleHttpServer.java
On Mon, 9 Dec 2024 13:03:06 GMT, Magnus Ihse Bursie wrote:
>> Some files have been modified in 2024, but the copyright year has not been
>> properly updated. This should be fixed.
>>
>> I have located these modified files using:
>>
>> git log --since="Jan 1" --name-only --pretty=format: | sor
On Tue, 3 Dec 2024 06:14:31 GMT, Jaikiran Pai wrote:
>> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java
>> line 68:
>>
>>> 66: try (Stream lines = Files.lines(filePath)) {
>>> 67: Optional firstLine = lines.findFirst();
>>> 68: re
On Mon, 2 Dec 2024 16:11:57 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which removes usages of
>> SecurityManager related APIs and some leftover related to SecurityManager
>> changes?
>>
>> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these
>>
On Mon, 2 Dec 2024 18:12:55 GMT, Sean Mullan wrote:
>> Now that JEP 486 has been integrated, `java.security` and `sun.security`
>> implementation dependencies on `System.getSecurityManager` and
>> `AccessController.doPrivileged` can be removed.
>>
>> This should cover most of the remaining cl
On Wed, 27 Nov 2024 19:59:24 GMT, Sean Mullan wrote:
>> Now that JEP 486 has been integrated, `java.security` and `sun.security`
>> implementation dependencies on `System.getSecurityManager` and
>> `AccessController.doPrivileged` can be removed.
>>
>> This should cover most of the remaining c
On Thu, 28 Nov 2024 17:28:59 GMT, Aleksei Efimov wrote:
>> The proposed change cleans-up `SecurityManager`, `doPriviledged`, and
>> `AccessController` usages from `java.naming`, `jdk.naming.rmi` and
>> `jdk.naming.dns` modules.
>>
>> One noteworthy change: The `java.naming.rmi.security.manager
On Thu, 28 Nov 2024 16:30:36 GMT, Alan Bateman wrote:
>> Aleksei Efimov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove com.sun.jndi.ldap.VersionHelper
>
> src/java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.jav
On Thu, 28 Nov 2024 13:58:58 GMT, Aleksei Efimov wrote:
>> The proposed change cleans-up `SecurityManager`, `doPriviledged`, and
>> `AccessController` usages from `java.naming`, `jdk.naming.rmi` and
>> `jdk.naming.dns` modules.
>>
>> One noteworthy change: The `java.naming.rmi.security.manager
On Mon, 25 Nov 2024 20:06:33 GMT, Volkan Yazıcı wrote:
>> Addresses [8344222](https://bugs.openjdk.org/browse/JDK-8344222) and removes
>> `SecurityManager` and `doPrivileged()` usages from `Http(s)URLConnection`
>> and `HttpConnectSocketImpl`. `tier2` and `tier3` results are on their way.
>
> V
On Fri, 22 Nov 2024 14:31:21 GMT, Volkan Yazıcı wrote:
> Addresses [8344222](https://bugs.openjdk.org/browse/JDK-8344222) and removes
> `SecurityManager` and `doPrivileged()` usages from `Http(s)URLConnection` and
> `HttpConnectSocketImpl`. `tier2` and `tier3` results are on their way.
LGTM
-
On Thu, 21 Nov 2024 17:36:03 GMT, Sean Mullan wrote:
> Some additional text in two `javax.net.ssl` APIs related to access control
> context was missed as part of JEP 483. This behavior no longer applies now
> that the Security Manager is permanently disabled and has been removed.
>
> The imple
On Sat, 16 Nov 2024 01:59:43 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which removes calls to
>> `SecurityManager` and `AccessController.doPrivileged()` from the
>> `ProxySelector` and `DefaultProxySelector` classes?
>>
>> Apart from the trivial removing of those cal
On Fri, 15 Nov 2024 09:00:29 GMT, Eirik Bjørsnøs wrote:
> Please review this PR to clean up SM use in `java.net.Authenticator`,
> `java.net.CookieHandler`, and `java.net.ResponseCache` after JEP 486
> integration.
>
> * `Authenticator` is updated to remove calls to SM::checkPermission`
> * `Co
On Thu, 14 Nov 2024 20:40:46 GMT, Daniel Fuchs wrote:
> Please find here a patch that cleans up the java.net.http module code to
> remove permission checks and doPriviliged calls.
> This was mostly mechanical.
This pull request has now been integrated.
Changeset: 40a055eb
Author:
On Fri, 15 Nov 2024 09:10:51 GMT, Daniel Fuchs wrote:
>> test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContext.java
>> line 45:
>>
>>> 43: * Creates a simple usable SSLContext for SSLSocketFactory
>>> 44: * or a HttpsSe
On Fri, 15 Nov 2024 13:15:42 GMT, Jaikiran Pai wrote:
>> Daniel Fuchs 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 contain
> Please find here a patch that cleans up the java.net.http module code to
> remove permission checks and doPriviliged calls.
> This was mostly mechanical.
Daniel Fuchs has updated the pull request incrementally with one additional
commit since the last revision:
Jaikiran&#
On Fri, 15 Nov 2024 10:31:11 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which removes calls to
> `SecurityManager` and `AccessController.doPrivileged()` from the
> `ProxySelector` and `DefaultProxySelector` classes?
>
> Apart from the trivial removing of those calls, t
On Fri, 15 Nov 2024 09:00:29 GMT, Eirik Bjørsnøs wrote:
> Please review this PR to clean up SM use in `java.net.Authenticator`,
> `java.net.CookieHandler`, and `java.net.ResponseCache` after JEP 486
> integration.
>
> * `Authenticator` is updated to remove calls to SM::checkPermission`
> * `Co
> Please find here a patch that cleans up the java.net.http module code to
> remove permission checks and doPriviliged calls.
> This was mostly mechanical.
Daniel Fuchs has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the
> Please find here a patch that cleans up the java.net.http module code to
> remove permission checks and doPriviliged calls.
> This was mostly mechanical.
Daniel Fuchs has updated the pull request incrementally with one additional
commit since the last revision:
Review
On Thu, 14 Nov 2024 20:53:02 GMT, Michael McMahon wrote:
>> Please find here a patch that cleans up the java.net.http module code to
>> remove permission checks and doPriviliged calls.
>> This was mostly mechanical.
>
> src/java.net.http/share/classes/jdk/internal/net/http/HttpClientBuilderImpl.
On Thu, 14 Nov 2024 21:17:01 GMT, Michael McMahon wrote:
>> Please find here a patch that cleans up the java.net.http module code to
>> remove permission checks and doPriviliged calls.
>> This was mostly mechanical.
>
> test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/Si
Please find here a patch that cleans up the java.net.http module code to remove
permission checks and doPriviliged calls.
This was mostly mechanical.
-
Commit messages:
- 8344228: Revisit SecurityManager usage in java.net.http after JEP 486
integration
Changes: https://git.openjdk
On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote:
> Currently, the man pages are stored as troff (a text format) in the open
> repo, and a content-wise identical copy is stored as markdown (another text
> format) in the closed repo.
>
> Since markdown is preferred to troff in terms o
On Tue, 12 Nov 2024 18:47:46 GMT, Alan Bateman wrote:
>> Removes the SecurityManager usage from Thread + friends.
>>
>> In Thread, the getContextClassLoader method is no longer caller-sensitive
>> method.
>>
>> JavaLangAccess.newThreadWithAcc is removed and jdk.internal.access is no
>> longer
On Sat, 2 Nov 2024 22:25:06 GMT, ExE Boss wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 200 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>> - Modify three RMI tests
On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Wed, 23 Oct 2024 11:54:39 GMT, Alan Bateman wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 97 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>> - Change apiNote to d
On Tue, 22 Oct 2024 11:50:13 GMT, Michael McMahon wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 97 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>> - Change apiNote t
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Wed, 16 Oct 2024 11:36:18 GMT, Jaikiran Pai wrote:
>> This brings in CPU24_10 changes into master branch.
>
> Jaikiran Pai 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 Tue, 15 Oct 2024 16:34:40 GMT, Severin Gehwolf wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> mai
On Tue, 15 Oct 2024 15:21:32 GMT, Alan Bateman wrote:
>> src/java.logging/share/classes/java/util/logging/LogManager.java line 2430:
>>
>>> 2428: @Deprecated(since="17", forRemoval=true)
>>> 2429: public void checkAccess() {
>>> 2430: throw new SecurityException();
>>
>> Though
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Tue, 28 May 2024 01:46:01 GMT, Bradford Wetmore wrote:
> It's too late now, but I might have suggested a short sleep between attempts.
@bradfordwetmore what would be the rationale for that? If the ReuseAddr::run
method throws BindException, then retrying immediately should hopefully let us
On Thu, 23 May 2024 08:42:00 GMT, Daniel Fuchs wrote:
> This is one of these tests that is not really fixable if any other process
> that might open a socket runs concurrently with it on the same machine:
> nothing can guarantee that if you open a socket, close it, then open a new
&g
ee. It might work most of
> the time, but success can’t be guaranteed.
>
> The only thing we can do in order to attempt to minimize noisy intermittent
> failures is retry the whole test if a BindException is thrown.
Daniel Fuchs has updated the pull request incrementally with one addi
This is one of these tests that is not really fixable if any other process that
might open a socket runs concurrently with it on the same machine: nothing can
guarantee that if you open a socket, close it, then open a new socket on the
same port, that port will still be free. It might work most
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons wrote:
> Please review a set of updates to clean up use of `/**` comments in the
> vicinity of declarations.
>
> There are various categories of update:
>
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or imp
On Wed, 17 Apr 2024 01:09:30 GMT, Jaikiran Pai wrote:
> This brings in the CPU24_04 changes.
This looks reasonable. I haven't been involved in all the fixes here - but I
haven't spotted anything obviously wrong. The changes to the ConnectionPool
look right. If some of the fixes had conflicts t
On Tue, 2 Apr 2024 13:38:00 GMT, Daniel Fuchs wrote:
>> Sean Coffey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> incorporate testcase feedback from Daniel
>
> test/jdk/jdk/security/logging/RecursiveEven
1 - 100 of 209 matches
Mail list logo
