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

Chris Plummer cjplummer at openjdk.org
Wed Apr 5 21:50:06 UTC 2023


On Wed, 5 Apr 2023 21:37:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> 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?
>
> @plummercj, I'e updated CR with more detailed information. Hope it makes clearer why this change is needed. Here is the text.
> 
> "
> VMConnection runs debuggee using "test.classes" as a classpath for debuggee classes. It works fine when test and TestScaffold.java are located in the same directory and are both compiled into "test.classes" location. However, it causes test failures when the virtual thread factory (wrapper) is enabled and the test is not located in the same directory as TestScaffold. Such tests use TestScaffold as a testlibrary. (They have ' * @library ..' or something like similar).
> So TestScaffold is not included in 'test.classes' which include tests only. However, it is included as all testlibrary classes in "test.class.path" classparth.
> 
> It is needed to use "test.class.path" to be able to use TestScaffolld as debugee wrapper Might be it better to always use "test.class.path" as classpath for debugee to minimize the difference between standard and "virtual" execution.
> "
> 
> Yes, it would be better to change "When we jtreg with plugin" to "When 'main wrapper' is used". 
> 
> Before updating the comments I want to confirm if we want to keep "test.classes" for standard execution or change it to use  "test.class.path" always.

I'm ok with always using test.class.path.

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

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


More information about the serviceability-dev mailing list