On Sat, 2 Nov 2024 22:18:09 GMT, ExE Boss <d...@openjdk.org> 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 to work without the security manager: >> - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java >> - test/jdk/java/rmi/registry/readTest/CodebaseTest.java >> - >> test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java >> Also remove them from the problem list. >> - Remove two obsolete RMI tests: >> - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java >> - >> test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java >> Adjust two tests to run without the Security Manager: >> - >> test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java >> - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java >> Remove all of these tests from the problem list. >> - In staticPermissionsOnly(), change "current policy binding" to "current >> policy" so wording is consistent with the API note that follows. >> - Added API Notes to ProtectionDomain clarifying that the current policy >> always >> grants no permissions. A few other small changes to Policy and PD. >> - Merge branch 'master' into jep486 >> - JAXP tests: organize imports of a few tests >> - Improve description of Executors.privilegedThreadFactory >> - rename TestAppletLoggerContext.java as suggested in util test review >> - clientlibs: Javadoc cleanup >> - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b > > src/java.base/share/classes/java/lang/System.java line 2338: > >> 2336: * Invoked by VM. Phase 3 is the final system initialization: >> 2337: * 1. eagerly initialize bootstrap method factories that might >> interact >> 2338: * negatively with custom security managers and custom class >> loaders > > They might still interact negatively with custom class loaders though.
The context here is custom a security manager doing string concatenation, this has required StringConcatFactory be eagerly initialized or security managers set on the command line to have been compiled with -XDstringConcat=inline. I think your question is about overriding the system class loader and whether its initialisation can use string concatenation reliably. That's a good thing to add a test for. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826916876
