I note that javac emits the following messages for invalid entries in search paths:

warning: [path] bad path element "${PATH}": no such file or directory

@sormuras
Yes, exactly. This change makes the ConsoleLauncher behave more like javac in that it logs invalid classpath roots instead of silently ignoring them. While javac emits a warning to stderr, JUnit logs them at INFO level so that users can see misconfigurations during discovery.

Love it.

But should this not be WARN's ? Or as pointed out for javac - stderr message ?

@maxandersen

Good point. Updated the log level from INFO to WARN so that users can better notice invalid search path roots.

@maxandersen

Thanks for the feedback! I switched the level to WARN, but that surfaced an issue in platform-tooling-support-tests (StandaloneTests.execute*) where console output expectations are strict.

To keep the console output stable while still alerting users, would you prefer:

1. WARN only for explicitly provided roots (e.g., via --scan-class-path <paths> or --classpath), while system-derived roots are filtered silently (or at DEBUG), or

2. WARN for all invalid roots, but accept extra warnings on stderr and update the expected output accordingly?

I can implement (1) right away; it avoids changing the console output in common scenarios and keeps the tests green. If you’d rather go with (2), I’ll update the tests and docs.

Also, do we want to mention this behavior in the User Guide (ConsoleLauncher section)?

@maxandersen

Found the root cause of the test failure.

I was running the build in Korea (ko_KR locale), and the execute-related tests did not explicitly set the language.
This caused JUL log levels in the output to be localized (INFO → 정보), so the expected-err.txt assertions failed.

I fixed this by forcing -Duser.language=en and -Duser.country=US in the relevant tests.