RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual

[Leonid Mesnik]

On Thu, 29 May 2025 07:28:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this small test fix. The test launches a child process with the only purpose of validating that the load of the main class (`emptynumbootstrapmethods1`/`emptynumbootstrapmethods2`) completes successfully and doesn’t throw `ClassFormatError`. The class doesn’t define a main method, so later during execution of `LauncherHelper.validateMainMethod` the child VM exits with the following error message which we check from the `OutputAnalyzer` output:
>> 
>> 
>> Error: Main method not found in class emptynumbootstrapmethods1, please define the main method as:
>>    public static void main(String[] args)
>> or a JavaFX application class must extend javafx.application.Application
>> 
>> 
>> The issue when the test is run with `TEST_THREAD_FACTORY=Virtual` is that loading of `emptynumbootstrapmethods1` is done in `jdk.test.lib.process.ProcessTools.main` (the actual entry point), which instead of calling `MethodFinder.findMainMethod(mainClass)` and aborting if result is null like `LauncherHelper` uses
>> `Method mainMethod = c.getMethod("main", new Class<?>[] { String[].class });` which throws an exception instead and the test exits with the following error message:
>> 
>> 
>> [Exception in thread "main" java.lang.NoSuchMethodException: emptynumbootstrapmethods1.main([Ljava.lang.String;)
>> at java.base/java.lang.Class.getMethod(Class.java:2166)
>> at jdk.test.lib.process.ProcessTools.main(ProcessTools.java:984)
>> 
>> 
>> The proposed fix adjusts the output we check for based on whether the test was run on a platform thread or a virtual thread.
>> 
>> Thanks,
>> Patricio
>
> test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java line 58:
> 
>> 56:         output.shouldNotContain("java.lang.ClassFormatError");
>> 57:         output.shouldHaveExitValue(1);
>> 58:         if (Thread.currentThread().isVirtual()) {
> 
> Just to be clear with `TEST_THREAD_FACTORY=Virtual` are all launched JVMs modified such that a virtual thread is created to invoke "main" instead of the normal platform thread? It just isn't clear why being virtual in the parent VM implies the child was also virtual, unless everything is virtual.
> 
> FWIW I think this highlights a deficiency with how TEST_THREAD_FACTORY=Virtual actually works.

Yes, the the main is executed in virtual thread and also it runs all forked processes with wrapper that run main in virtual thread. 
The another, might be more clear solution would to check it with
`static final boolean vthreadMode = "Virtual".equals(System.getProperty("test.thread.factory"));`

or even make library method for this in the future.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25509#discussion_r2114856783