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