Fix TestCompilerTests with locales other than english

[quaff]

		assertThatExceptionOfType(CompilationException.class).isThrownBy(
				() -> TestCompiler.forSystem().failOnWarning().withSources(
						SourceFile.of(HELLO_DEPRECATED), main).compile(compiled -> {
				})).withMessageContaining("warnings found and -Werror specified");

is failed since error message may not be english before this commit.

[quaff]

It's introduced by 4b14a0b @snicoll

[snicoll]

Ah good catch, @quaff thank you. I think I am probably going to polish that to use a different assertion.

[snicoll]

Turns out I think we should fix this differently. Thanks for the report but we'll follow-up on #31408.

[quaff]

@snicoll I'm afraid your fix doesn't work, It still report localized error message.

> Task :spring-core-test:test FAILED
TestCompilerTests > compileWhenSourceUseDeprecateCodeAndFailOnWarningIsSet() FAILED
    java.lang.AssertionError at TestCompilerTests.java:176

[snicoll]

Damn, thanks for testing and reporting back. I wonder how it is different from your fix. The only thing I've done is not hardcoding the locale but rather make it configurable. What did I miss?

[quaff]

diagnostic is already localized.
I created #31532 to fix it.

[snicoll]

diagnostic is already localized.

That's odd. Then Diagnostic#getMessage(Locale) is not reliable. Rather than introducing another way to do the assertion, I think we need to fix how the locale is specified. Adding the code makes the Locale argument useless.

I think the PR should rather change this.compiler.getStandardFileManager to specify the Locale in the second argument. Can you try that since you have a way to easily reproduce?

[quaff]

diagnostic is already localized.

That's odd. Then Diagnostic#getMessage(Locale) is not reliable. Rather than introducing another way to do the assertion, I think we need to fix how the locale is specified. Adding the code makes the Locale argument useless.

I think the PR should rather change this.compiler.getStandardFileManager to specify the Locale in the second argument. Can you try that since you have a way to easily reproduce?

		StandardJavaFileManager standardFileManager = this.compiler.getStandardFileManager(
				null, this.locale, null);

it doesn't work.

[snicoll]

CompilationTask#setLocale then?

[quaff]

CompilationTask#setLocale then?

	private DynamicClassLoader compile() {
		ClassLoader classLoaderToUse = (this.classLoader != null ? this.classLoader
				: Thread.currentThread().getContextClassLoader());
		List<DynamicJavaFileObject> compilationUnits = this.sourceFiles.stream().map(
				DynamicJavaFileObject::new).toList();
		StandardJavaFileManager standardFileManager = this.compiler.getStandardFileManager(
				null, this.locale, null);
		DynamicJavaFileManager fileManager = new DynamicJavaFileManager(
				standardFileManager, classLoaderToUse, this.classFiles, this.resourceFiles);
		if (!this.sourceFiles.isEmpty()) {
			Errors errors = new Errors(this.locale);
			CompilationTask task = this.compiler.getTask(null, fileManager, errors,
					this.compilerOptions, null, compilationUnits);
			task.setLocale(this.locale);
			if (!this.processors.isEmpty()) {
				task.setProcessors(this.processors);
			}
			boolean result = task.call();
			if (!result || errors.hasReportedErrors()) {
				throw new CompilationException(errors.toString(), this.sourceFiles, this.resourceFiles);
			}
		}
		return new DynamicClassLoader(classLoaderToUse, this.classFiles, this.resourceFiles,
				fileManager.getDynamicClassFiles(), fileManager.getDynamicResourceFiles());
	}

Not working.

[snicoll]

I went down a rabbit hole and I am not sure why this does not work. It goes all the way down to ResourceBundle.getBundle("com.sun.tools.javac.resources.compiler", Locale.ENGLISH) that returns the one of the default locale no matter what. Perhaps it's a module visibility problem?

In any case. I've reverted the support in #31536 and relaxed the assertion.