Spring Fix TestCompilerTests with locales other than english

        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.

Comment From: quaff

It's introduced by https://github.com/spring-projects/spring-framework/commit/4b14a0b42cb407276ab205221fbcea907f64cd38 @snicoll

Comment From: snicoll

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

Comment From: snicoll

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

Comment From: 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

Comment From: 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?

Comment From: quaff

diagnostic is already localized. I created https://github.com/spring-projects/spring-framework/pull/31532 to fix it.

Comment From: 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?

Comment From: 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.

Comment From: snicoll

CompilationTask#setLocale then?

Comment From: 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.

Comment From: 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.