RFR: 8305608: Change VMConnection to use "test.class.path"instead of "test.classes"

Chris Plummer cjplummer at openjdk.org
Wed Apr 5 20:12:14 UTC 2023


On Wed, 5 Apr 2023 01:05:44 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The "test.class.path" is complete classpath required to run test. It included test.classes as well as testlibrary and some other classes. The tests located in com/sun/jdi/<subdirectory> uses 'com/sun/jdi' as a testlibrary.
>> The better comment would be
>> // When we run jtreg with plugin, the full classpath including testlibrary is required to use TestScaffold is required
>> 
>> However, before fixing this comment I would like to see if there are any objections against using "test.class.path"  in all cases. It would minimize difference in virtual and standard mode. 
>> Is there are any reason to use "test.classes" at all?
>
> I'd prefer to always use the "test.class.path" as it is a complete classpath required to run test.
> 
>> The better comment would be
>> // When we run jtreg with plugin, the full classpath including testlibrary is required to use TestScaffold is required
> 
> I guess, you are going to remove this duplication with "is required". :)

I think the CR should explain this test.classes vs test.class.path difference, and also explain why the classpath requirements are different when using virtual threads. You say that "TestScaffold should be also in classpath", but don't explain why. It's also not clear to me why only tests that are in subdirs are impacted when running with the wrapper.

Also, when you say "When we run jtreg with plugin..", do you mean with the wrapper, not the plugin?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13339#discussion_r1158962727


More information about the serviceability-dev mailing list