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