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
On Mon, 20 Jan 2025 16:55:10 GMT, Magnus Ihse Bursie wrote:
> > The problem is, that such IBM links do not work very long. In one or a view
> > years this link again might point to nirvana.
>
> Should we remove it instead then?
I would be OK with just dropping the link.
-
PR Comm
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, 16 Dec 2024 20:24:20 GMT, Tim Prinzing wrote:
>> Adds a JFR event for socket connect operations.
>>
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also
>> check for connect events.
>
> Tim Prinzing has updated the pull request incrementally with one additiona
On Tue, 10 Dec 2024 21:41:18 GMT, Tim Prinzing wrote:
>> Adds a JFR event for socket connect operations.
>>
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also
>> check for connect events.
>
> Tim Prinzing has updated the pull request incrementally with one additiona
On Tue, 10 Dec 2024 21:41:18 GMT, Tim Prinzing wrote:
>> Adds a JFR event for socket connect operations.
>>
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also
>> check for connect events.
>
> Tim Prinzing has updated the pull request incrementally with one additiona
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 Thu, 5 Dec 2024 04:38:04 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to address
>> https://bugs.openjdk.org/browse/JDK-8341551?
>>
>> The primary work in this PR is the specification of the previously existing
>> `sun.misc.URLClassPath.disableJarChec
Hi Eirik,
Yes, the situation we're in is far from perfect. I've never been a big
fan of considering that an empty value means "true": if you're going
to pass a System property, you can go the extra mile and supply
its value too, which should make the intent uncontroversial. Note that
not passing
On Wed, 4 Dec 2024 15:58:41 GMT, Jaikiran Pai wrote:
>> test/jdk/jdk/internal/loader/URLClassPath/JarCheckTest.java line 60:
>>
>>> 58: * @run junit/othervm -Dsun.misc.URLClassPath.disableJarChecking
>>> JarCheckTest
>>> 59: * @run junit/othervm -Dsun.misc.URLClassPath.disableJarChecking=true
On Wed, 4 Dec 2024 15:46:28 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to address
>> https://bugs.openjdk.org/browse/JDK-8341551?
>>
>> The primary work in this PR is the specification of the previously existing
>> `sun.misc.URLClassPath.disableJarChec
On Sat, 23 Nov 2024 08:36:03 GMT, Alan Bateman wrote:
>> Tim Prinzing has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added more tests for socket connect events.
>>
>> - SocketAdapter connect
>> - SocketAdapter connect with except
On Tue, 3 Dec 2024 15:40:02 GMT, Tim Prinzing wrote:
>> Adds a JFR event for socket connect operations.
>>
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also
>> check for connect events.
>
> Tim Prinzing has updated the pull request with a new target base due to a
On Tue, 3 Dec 2024 00:40:24 GMT, Tim Prinzing wrote:
>> Adds a JFR event for socket connect operations.
>>
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also
>> check for connect events.
>
> Tim Prinzing has updated the pull request incrementally with one additional
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 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 Thu, 28 Nov 2024 12:19:25 GMT, Daniel Fuchs wrote:
> A few minor things were missed by JDK-8344235. Some unused variables can be
> removed, some @SuppressWranings are now redundant and some comments
> ,mentioning the access control context can be deleted.
This pull request has
A few minor things were missed by JDK-8344235. Some unused variables can be
removed, some @SuppressWranings are now redundant and some comments ,mentioning
the access control context can be deleted.
-
Commit messages:
- 8345175: Further cleanup in java.logging and jdk.internal.logg
On Mon, 25 Nov 2024 16:22:16 GMT, Sean Mullan wrote:
>> Daniel Fuchs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review feedback
>
> src/java.base/share/classes/jdk/internal/logger/LazyLo
On Thu, 21 Nov 2024 01:45:56 GMT, Brian Burkhalter wrote:
>> Remove some occurrences of `GetPropertyAction` overlooked in #22219 and
>> #22132.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8344659: System.getPropert
On Wed, 20 Nov 2024 21:03:33 GMT, Roger Riggs wrote:
>> Removed use of SecurityManager to check permissions.
>> Relaxed defensive copying of byte arrays (due to lack of SM)
>>
>> Refresh of PR#22168 Including review comments made there.
>
> Roger Riggs has updated the pull request incrementally
On Wed, 20 Nov 2024 19:39:58 GMT, Daniel Fuchs wrote:
> This PR remove usage of SecurityManager, doPrivileges, etc... from
> `java.logging` and `java.base/jdk.internal.logger`
>
> Only notable hack - Logger.checkPermission() no longer checks permissions,
> but has be
On Thu, 21 Nov 2024 06:50:48 GMT, Jaikiran Pai wrote:
> Hello Daniel, the changes look good to me. However, these changes appear to
> include both JEP 486 related updates as well as the JEP 491 (the reverting of
> ReentrantLock usage in favour of synchronized). Doing this clean up together
> I
On Wed, 20 Nov 2024 20:29:06 GMT, Roger Riggs wrote:
>> Daniel Fuchs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review feedback
>
> src/java.base/share/classes/jdk/internal/logger/LoggerFinderLoad
in the
> Handler classes now that JEP 491 has been integrated.
Daniel Fuchs has updated the pull request incrementally with one additional
commit since the last revision:
Review feedback
-
Changes:
- all: https://git.openjdk.org/jdk/pull/22281/files
- new: https://git.ope
On Wed, 20 Nov 2024 19:42:58 GMT, Roger Riggs wrote:
> Removed use of SecurityManager to check permissions.
> Relaxed defensive copying of byte arrays (due to lack of SM)
>
> Refresh of PR#22168 Including review comments made there.
The changes to SystemLogger looks OK to me. Maybe you could ge
This PR remove usage of SecurityManager, doPrivileges, etc... from
`java.logging` and `java.base/jdk.internal.logger`
Only notable hack - Logger.checkPermission() no longer checks permissions, but
has been renamed into `ensureLogManagerInitialized()` in order to avoid
disturbing the initializat
On Wed, 20 Nov 2024 16:40:43 GMT, Aleksei Efimov wrote:
>> src/jdk.naming.rmi/share/classes/module-info.java line 64:
>>
>>> 62: * location} specified in the reference can be supported by a custom
>>> implementation of {@link
>>> 63: * javax.naming.spi.ObjectFactoryBuilder}. If a location is
On Wed, 20 Nov 2024 16:25:56 GMT, Aleksei Efimov wrote:
>> This PR permanently disable remote code downloading in JNDI/LDAP and
>> JNDI/RMI JDK providers, and contains the following changes:
>> - The following two properties are removed:
>> - `com.sun.jndi.ldap.object.trustURLCodebase`
>>
On Wed, 20 Nov 2024 16:25:56 GMT, Aleksei Efimov wrote:
>> This PR permanently disable remote code downloading in JNDI/LDAP and
>> JNDI/RMI JDK providers, and contains the following changes:
>> - The following two properties are removed:
>> - `com.sun.jndi.ldap.object.trustURLCodebase`
>>
On Wed, 20 Nov 2024 13:06:57 GMT, Aleksei Efimov wrote:
>> This PR permanently disable remote code downloading in JNDI/LDAP and
>> JNDI/RMI JDK providers, and contains the following changes:
>> - The following two properties are removed:
>> - `com.sun.jndi.ldap.object.trustURLCodebase`
>>
On Wed, 20 Nov 2024 06:52:11 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to remove
>> SecurityManager related API usages from `URLClassLoader` and its related
>> `URLClassPath`? This addresses https://bugs.openjdk.org/browse/JDK-8344223.
>>
>> The `URLCl
On Tue, 19 Nov 2024 00:53:22 GMT, Aleksei Efimov wrote:
>> This PR permanently disable remote code downloading in JNDI/LDAP and
>> JNDI/RMI JDK providers, and contains the following changes:
>> - The following two properties are removed:
>> - `com.sun.jndi.ldap.object.trustURLCodebase`
>>
On Tue, 19 Nov 2024 20:38:02 GMT, Roger Riggs wrote:
>> Aleksei Efimov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> clarify factory location usages in NamingManager and jdk.naming.rmi
>> module-info
>
> src/java.naming/share/classes/
On Tue, 19 Nov 2024 20:33:35 GMT, Roger Riggs wrote:
>> Aleksei Efimov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> clarify factory location usages in NamingManager and jdk.naming.rmi
>> module-info
>
> src/java.naming/share/classes/
On Tue, 19 Nov 2024 19:22:44 GMT, Aleksei Efimov wrote:
>> This PR permanently disable remote code downloading in JNDI/LDAP and
>> JNDI/RMI JDK providers, and contains the following changes:
>> - The following two properties are removed:
>> - `com.sun.jndi.ldap.object.trustURLCodebase`
>>
On Fri, 15 Nov 2024 17:03:50 GMT, Aleksei Efimov wrote:
> This PR permanently disable remote code downloading in JNDI/LDAP and JNDI/RMI
> JDK providers, and contains the following changes:
> - The following two properties are removed:
> - `com.sun.jndi.ldap.object.trustURLCodebase`
> - `
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 Tue, 5 Nov 2024 12:49:04 GMT, Andrey Turbanov wrote:
> Content of Hashtable `com.sun.jndi.ldap.LdapClient#defaultBinaryAttrs` is
> fully initialized in `` block.
> It means we can replace legacy synchronized `Hashtable` with immutable set.
Thanks for running the tests @AlekseiEfimov
---
On Tue, 5 Nov 2024 12:49:04 GMT, Andrey Turbanov wrote:
> Content of Hashtable `com.sun.jndi.ldap.LdapClient#defaultBinaryAttrs` is
> fully initialized in `` block.
> It means we can replace legacy synchronized `Hashtable` with immutable set.
Looks worthwhile and reasonable. What tests did you
On Wed, 6 Nov 2024 00:15:44 GMT, Tim Prinzing wrote:
>> Adds a JFR event for socket connect operations.
>>
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also
>> check for connect events.
>
> Tim Prinzing has updated the pull request incrementally with one additional
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 10:19:23 GMT, Eirik Bjørsnøs wrote:
> Please review this cleanup PR which updates a total of 12 links to external
> documentation or references in `java.base` to use https instead of plain text
> http.
>
> Links in `java.security` and `share/data/tzdata` are excluded from t
On Tue, 22 Oct 2024 13:36:43 GMT, Hannes Wallnöfer wrote:
> Please review a doc-only change to fix the order of javadoc @param tags in in
> various OpenJDK modules. This is the third and last PR to fix the order of
> @param tags in OpenJDK libraries.
>
> We are working on a javadoc feature to
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
1 - 100 of 435 matches
Mail list logo
