JDK-8350685 : java/lang/System/SecurityManagerWarnings.java fails with --enable-preview
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 25
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2025-02-25
  • Updated: 2025-04-15
  • Resolved: 2025-03-04
Related Reports
Causes :  
Duplicate :  
Relates :  
Description
Test java/lang/System/SecurityManagerWarnings.java fails with --enable-preview enabled.
The problem is that this test 
makes jar from SecurityManagerWarnings.java classes. Then it executes it with
java  -cp a.jar SecurityManagerWarnings run
and expects to have
java.lang.UnsupportedOperationException: Setting a Security Manager is not supported
        at java.base/java.lang.System.setSecurityManager(System.java:286)
        at A.run(SecurityManagerWarnings.java:113)
        at SecurityManagerWarnings.main(SecurityManagerWarnings.java:66)

However, running with --enable preview generates other error
java --enable-preview -cp a.jar SecurityManagerWarnings run
Error: Unable to initialize main class SecurityManagerWarnings
Caused by: java.lang.NoClassDefFoundError: jdk/test/lib/process/OutputAnalyzer

The problem is that SecurityManagerWarnings class depends on the OutputAnalyzer.

The class is not used in the executed path and VM don't try to resolve i. But VM with --enable-preview tries to verify the main() method and resolve all dependencies.

Not sure what spec says, but from my point of view test seems wrong. It is not a good to try to run classes with unresolved dependencies.
Comments
I am marking this test failure as a duplicate of JDK-8351188. Although we could workaround the issue in the test, it is not causing normal mach 5 tests to fail (since they don't run with --enable-preview), so I think it is best to wait and see how this issue is resolved first.
04-03-2025

> Given that issue, I think we should improve/fix the current implementation in the launcher code which triggers loading these additional application classes while trying to find non-public "main" methods. I will open a new issue to track this in the launcher, later today. I've created https://bugs.openjdk.org/browse/JDK-8351188 to track this in the launcher.
04-03-2025

> It's arguable that the implementation of JEP-495 should perhaps just try and look for declared methods by the name "main" and ignore resolving all other methods, but for now it relies on the existing reflection infrastructure of Class.findMethod(...). I see that JDK-8350714 is linked to the current issue and that seems to have caught a similar problem where --enable-preview attempts to load some class(es) that are asserted not to be loaded. Given that issue, I think we should improve/fix the current implementation in the launcher code which triggers loading these additional application classes while trying to find non-public "main" methods. I will open a new issue to track this in the launcher, later today.
04-03-2025

> But VM with --enable-preview tries to verify the main() method and resolve all dependencies. Looking at the issue description it wasn't clear why a "java -cp a.jar SecurityManagerWarnings <someprogarg>" would not throw a ClassNotFoundException for a class missing in a.jar but "java --enable-preview -cp a.jar SecurityManagerWarnings <someprogarg>" would. I had a look at this SecurityManagerWarnings test. The main class being launched in the test is SecurityManagerWarnings and this class is present in the a.jar which is in the classpath of "java". The SecurityManagerWarnings main class has a package private method: static OutputAnalyzer run(String prop, String cp) throws Exception { ... } The a.jar JAR file is missing the OutputAnalyzer. When launching without enable-preview, this "run" method never gets referenced in the application's lifetime and thus the OutputAnalyzer class is never attempted for class loading. When launched with --enable-preview, one of the preview features in the current mainline is JEP-495 (Simple Source Files and Instance Main Methods). The implementation of this preview feature, in the "java" launcher involves looking for non-public main() methods on the main class. The implementation of this, ends up calling getDeclaredMethods0(boolean publicOnly) on java.lang.Class. Internally, in the JVM, this ends up iterating and resolving all methods including the (non-public) "run()" method which requires loading the missing OutputAnalyzer class. Effectively, that results in a ClassNotFoundException for OutputAnalyzer class and explains why --enable-preview notices this missing class. It's arguable that the implementation of JEP-495 should perhaps just try and look for declared methods by the name "main" and ignore resolving all other methods, but for now it relies on the existing reflection infrastructure of Class.findMethod(...).
04-03-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/23864 Date: 2025-03-03 13:33:05 +0000
03-03-2025

Test java/lang/System/LoggerFinder/SignedLoggerFinderTest/SignedLoggerFinderTest.java fails because of the same issue. It tries to execute classes that couldn't be resolved.
25-02-2025