JDK-8155090 : String concatenation fails with a custom SecurityManager that uses concatenation
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-04-26
  • Updated: 2019-04-24
  • Resolved: 2016-04-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b117Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
Lets say we have a custom security manager that uses string concatenation (+) inside the method checkPermission(Permission).
When we call the method that does permission checking, it throws a java.lang.BootstrapMethodError.

Minimized test: 
-----------------------------------------

    SecurityManager sm = new SecurityManager() {

            @Override
            public void checkPermission(Permission perm) {
                String abc = "abc";
                String full = abc + "def";
            }
        };
        System.setSecurityManager(sm);
        ClassLoader cl = new ClassLoader() {};
    }
-----------------------------------------

Interesting that the spec for j.l.String says the following regarding concatenation: 
"The Java language provides special support for the string concatenation operator ( + ), ... String concatenation is implemented through the StringBuilder(or StringBuffer) class and its append method."
However, if we will replace {abc + "def"} with {new StringBuffer().append(abc).append("def").toString()}, the exception won't be thrown.

Reproduced with jdk9b104 and later.
Comments
So, for String Concat, we can untie the bootstrapping issue by setting up a default strategy (and other settings) early in the game. This lets custom SecurityManagers to continue with the transient settings without failure, and read the actual properties for us. This will only affect ISC in those SecurityManagers, but not for the rest of the code. See e.g. the suggested patch, which passes the test: http://cr.openjdk.java.net/~shade/8155090/webrev.00/
28-04-2016

What a weird bootstrapping issue. I think we should first solve a more generic version with lambdas first: JDK-8155659.
28-04-2016

If these properties are for internal use and set via -D, one option is to use jdk.internal.misc.VM::getSavedProperty and also preferably hide them not to expose in System::getProperties.
26-04-2016