RFR: 8344235: Revisit SecurityManager usage in java.logging after JEP 486 integration

Roger Riggs rriggs at openjdk.org
Wed Nov 20 20:53:09 UTC 2024


On Wed, 20 Nov 2024 19:39:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> 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 been renamed into `ensureLogManagerInitialized()` in order to avoid disturbing the initialization sequence of Logger/LogManager.
> 
> I am not 100% sure this is still needed - but I remember we had some entanglement issues in the past that had been hard to solve, so it seemed prudent to keep the call:
> 
> 
>     if (manager == null) {
>         manager = LogManager.getLogManager();
>     }
> 
> 
> where `manager` is a private volatile field in Logger.

Looks good

src/java.base/share/classes/jdk/internal/logger/LoggerFinderLoader.java line 114:

> 112: 
> 113:     private static Iterator<System.LoggerFinder> findLoggerFinderProviders() {
> 114:         final Iterator<System.LoggerFinder> iterator =

Could be simply be `return ` ... no need for a local var.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22281#pullrequestreview-2449637768
PR Review Comment: https://git.openjdk.org/jdk/pull/22281#discussion_r1850942628


More information about the core-libs-dev mailing list