jdk24 java/security/Security/ConfigFileTest FileNotFoundException scratch/3/ConfigFileTest/properties/extra���.properties

[pshipton]

https://openj9-jenkins.osuosl.org/job/Test_openjdknext_j9_sanity.openjdk_aarch64_mac_Personal_testList_2/6
jdk_security1_1
java/security/Security/ConfigFileTest.java

14:46:24  properties: unable to load security properties from /Users/jenkins/workspace/Test_openjdknext_j9_sanity.openjdk_aarch64_mac_Personal_testList_2/aqa-tests/TKG/output_17290177875280/jdk_security1_1/work/scratch/3/ConfigFileTest/properties/extra���.properties
14:46:24  java.io.FileNotFoundException: /Users/jenkins/workspace/Test_openjdknext_j9_sanity.openjdk_aarch64_mac_Personal_testList_2/aqa-tests/TKG/output_17290177875280/jdk_security1_1/work/scratch/3/ConfigFileTest/properties/extra���.properties
14:46:24  	at java.base/java.security.Security$SecPropLoader.loadExtraFromPath(Security.java:216)
14:46:24  	at java.base/java.security.Security$SecPropLoader.loadExtraHelper(Security.java:185)
14:46:24  	at java.base/java.security.Security$SecPropLoader.loadExtra(Security.java:164)
14:46:24  	at java.base/java.security.Security$SecPropLoader.loadAll(Security.java:129)
14:46:24  	at java.base/java.security.Security.initialize(Security.java:340)
14:46:24  	at java.base/java.security.Security.lambda$static$0(Security.java:327)
14:46:24  	at java.base/java.security.AccessController.doPrivileged(AccessController.java:692)
14:46:24  	at java.base/java.security.Security.<clinit>(Security.java:326)
14:46:24  	at java.base/sun.security.util.SecurityProperties.getOverridableProperty(SecurityProperties.java:57)
14:46:24  	at java.base/sun.security.util.SecurityProperties.privilegedGetOverridable(SecurityProperties.java:48)
14:46:24  	at java.base/sun.security.util.SecurityProperties.includedInExceptions(SecurityProperties.java:72)
14:46:24  	at java.base/sun.security.util.SecurityProperties.<clinit>(SecurityProperties.java:36)
14:46:24  	at java.base/sun.security.util.FilePermCompat.<clinit>(FilePermCompat.java:43)
14:46:24  	at java.base/java.io.FilePermission.init(FilePermission.java:319)
14:46:24  	at java.base/java.io.FilePermission.<init>(FilePermission.java:490)
14:46:24  	at java.base/sun.net.www.protocol.file.FileURLConnection.getPermission(FileURLConnection.java:222)
14:46:24  	at java.base/sun.security.util.LazyCodeSourcePermissionCollection.ensureAdded(LazyCodeSourcePermissionCollection.java:69)
14:46:24  	at java.base/sun.security.util.LazyCodeSourcePermissionCollection.toString(LazyCodeSourcePermissionCollection.java:115)
14:46:24  	at java.base/java.lang.String.valueOf(String.java:5338)
14:46:24  	at java.base/java.lang.StringBuilder.append(StringBuilder.java:173)
14:46:24  	at java.base/java.security.ProtectionDomain.toString(ProtectionDomain.java:434)
14:46:24  	at java.base/java.lang.String.valueOf(String.java:5338)
14:46:24  	at java.base/java.lang.StringBuilder.append(StringBuilder.java:173)
14:46:24  	at java.base/java.security.SecureClassLoader$1.apply(SecureClassLoader.java:231)
14:46:24  	at java.base/java.security.SecureClassLoader$1.apply(SecureClassLoader.java:222)
14:46:24  	at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1719)
14:46:24  	at java.base/java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:222)
14:46:24  	at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)

14:46:24  java.lang.reflect.InvocationTargetException
14:46:24  	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119)
14:46:24  	at java.base/java.lang.reflect.Method.invoke(Method.java:579)
14:46:24  	at Executor.run(ConfigFileTest.java:794)
14:46:24  	at ConfigFileTest.main(ConfigFileTest.java:97)
14:46:24  	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
14:46:24  	at java.base/java.lang.reflect.Method.invoke(Method.java:579)
14:46:24  	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
14:46:24  	at java.base/java.lang.Thread.run(Thread.java:1588)
14:46:24  Caused by: java.lang.RuntimeException: 'Initial security property: extra•.properties=applied' missing from stdout/stderr
14:46:24  	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253)
14:46:24  	at PropsFile.assertApplied(ConfigFileTest.java:521)
14:46:24  	at Executor.assertSuccess(ConfigFileTest.java:883)
14:46:24  	at ConfigFileTest.specialCharsIncludes(ConfigFileTest.java:214)
14:46:24  	at ConfigFileTest.testUnicodeIncludes1(ConfigFileTest.java:219)
14:46:24  	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
14:46:24  	... 7 more

[github-actions]

Issue Number: 20357
Status: Open
Recommended Components: comp:test, comp:vm, comp:jclextensions
Recommended Assignees: pshipton, babsingh, jasonfengj9

[babsingh]

@theresa-m Assigning it to you since it is related to the Security Manager.

[theresa-m]

This looks like a string encoding issue. OpenJDK introduced some changes to reading security properties with Java 24 openjdk/jdk#16483.

The testUnicodeIncludes tests are failing due to not being able to find the the properties file containing a special character.

The test creates a properties file with a special character in the name and passes it in to a new process as a jvm argument -Djava.security.properties=<filename>. The special character is not read properly into the new process so the file name cannot be found.

java.io.FileNotFoundException: /Users/theresamammarella/openj9builds/openj9-openjdk-jdk24/build/run-test-prebuilt/test-support/jtreg_test_jdk_java_security_Security_ConfigFileTest_java/scratch/0/ConfigFileTest/properties/extra���.properties
        at java.base/java.security.Security$SecPropLoader.loadExtraFromPath(Security.java:221)
        at java.base/java.security.Security$SecPropLoader.loadExtraHelper(Security.java:189)
        at java.base/java.security.Security$SecPropLoader.loadExtra(Security.java:166)
        at java.base/java.security.Security$SecPropLoader.loadAll(Security.java:129)
        at java.base/java.security.Security.initialize(Security.java:342)
        at java.base/java.security.Security.<clinit>(Security.java:331)
        at ConfigFileTest.main(ConfigFileTest.java:86)

[pshipton]

Exclude it via adoptium/aqa-tests#5912

[theresa-m]

This test is failing because J9 is using ASCII as the default encoding for macos and the java.security.properties property value has a special character '\u2022'.

J9 reads the argument starting https://github.com/eclipse-openj9/openj9/blob/master/runtime/vm/vmprops.c#L1419 and the call to nl_langinfo(CODESET) at https://github.com/eclipse-openj9/openj9-omr/blob/openj9/port/common/omrstr.c#L2299 returns 'US-ASCII'.

This seems incorrect to me because at least on my machine a standalone call to nl_langinfo(CODESET) returns UTF8 but in running the test locally it returns US-ASCII.

Adding -Xargencoding:utf8 to the executed command in https://github.com/ibmruntimes/openj9-openjdk-jdk24/blob/openj9/test/jdk/java/security/Security/ConfigFileTest.java#L840 makes the test pass.

[theresa-m]

I see that setting export LC_ALL := C causes the character encoding to be changed to US-ASCII. https://github.com/ibmruntimes/openj9-openjdk-jdk24/blob/openj9/make/RunTestsPrebuiltSpec.gmk#L31

@pshipton I see you've worked on encoding issues previously, can you recommend a way to resolve this? I'm wondering if J9 should be using utf8 as the default setting for all platforms (https://github.com/eclipse-openj9/openj9/blob/master/runtime/vm/vmprops.c#L1419) due to JEP 400?

[pshipton]

It seems to be working as designed. Does Adoptium have a different behavior?

[theresa-m]

It seems to be working as designed. Does Adoptium have a different behavior?

Yes OpenJDK builds pass this test.

[pshipton]

We need to figure out what is different. I looked on Linux instead of Mac, but setting export LC_ALL := C changes the sun.jnu.encoding to ASCII (ANSI_X3.4-1968) for both OpenJ9 and Hotspot. This seems to be the system property that controls the file name encoding.

[theresa-m]

I'm getting different results on Mac, I think the problem is only on this platform. sun.jnu.encoding is always UTF-8.

It looks like OpenJDK has set sun.jnu.encoding to always be UTF-8 on Mac. OpenJ9 uses nl_langinfo(CODESET) to determine the encoding for command line arguments and not sun.jnu.encoding which explains the difference.

https://bugs.openjdk.org/browse/JDK-8003228

[pshipton]

Ok, we can make that change for OpenJ9 too.

[theresa-m]

This issue has been resolved by #21170 and adoptium/aqa-tests#5967