RFR: 8366678: Use JUnit in test/langtools/tools/javac [v2]

[Christian Stein]

On Thu, 4 Sep 2025 14:23:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> We either help Jupiter to select the right constructor or rewrite the test class to have a single one.
>> 
>> An alternative implemented in a future Jupiter version could be to ignore `private` constructors. On the other hand, having the need and ability to create "detached" test instances, not managed by Jupiter, is very uncommon. As those detached instances won't take part in Jupiter's test instance lifecycle: https://docs.junit.org/current/user-guide/#writing-tests-test-instance-lifecycle
>
> Well, uncommon as it is claimed to be, it already appeared twice in the set of tests in javac 😕

I think, these two classes started out as normal programs; using `main` methods as their entry-points. In such programs, you can and need to create instances to your liking, even of the static program-defining class.
Using a framework, shifts the instantion duty to (most of the time) reflection, under the framework's control. That way, `@Before[After]All|Each` and other lifecycle callbacks are realized. Usually, you then never write `new MyObjectTest()` with your test code. That would be "detached" test instances; not par-taking in the test lifecycle.

When those two test classes were migrated to use TestNG, they ended up with framework-managed instances (where @Test-annotated methods serve as entry-points) asserting stuff against "detached" instances created by the test logic.

Therefore, I suggest to "just" help JUnit here to select the correct constructor - which TestNG does by default.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27046#discussion_r2322594772