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

Daniel Fuchs dfuchs at openjdk.org
Wed Nov 20 19:44:27 UTC 2024


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.

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

Commit messages:
 - 8344235: Revisit SecurityManager usage in java.logging after JEP 486 integration
 - 8344235: Revisit SecurityManager usage in java.logging after JEP 486 integration

Changes: https://git.openjdk.org/jdk/pull/22281/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22281&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344235
  Stats: 953 lines in 17 files changed: 47 ins; 746 del; 160 mod
  Patch: https://git.openjdk.org/jdk/pull/22281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22281/head:pull/22281

PR: https://git.openjdk.org/jdk/pull/22281


More information about the core-libs-dev mailing list