ResourceBundleMessageSource should avoid ResourceBundle.Control on Jigsaw [SPR-16776]

[spring-projects-issues]

Leonardo Zanivan opened SPR-16776 and commented

ResourceBundleMessageSource broken when using Java 9 module system.

Using a custom ResourceBundle.Control isn't supported by Java 9 Module system.

Strack trace:

java.lang.UnsupportedOperationException: ResourceBundle.Control not supported in named modulesjava.lang.UnsupportedOperationException: ResourceBundle.Control not supported in named modules at java.base/java.util.ResourceBundle.checkNamedModule(ResourceBundle.java:1547) at java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:1508) at spring.context@5.0.5.RELEASE/org.springframework.context.support.ResourceBundleMessageSource.doGetBundle(ResourceBundleMessageSource.java:223) at spring.context@5.0.5.RELEASE/org.springframework.context.support.ResourceBundleMessageSource.getResourceBundle(ResourceBundleMessageSource.java:189) at spring.context@5.0.5.RELEASE/org.springframework.context.support.ResourceBundleMessageSource.resolveCodeWithoutArguments(ResourceBundleMessageSource.java:132) at spring.context@5.0.5.RELEASE/org.springframework.context.support.AbstractMessageSource.getMessageInternal(AbstractMessageSource.java:212) at spring.context@5.0.5.RELEASE/org.springframework.context.support.AbstractMessageSource.getMessage(AbstractMessageSource.java:169) at spring.context@5.0.5.RELEASE/org.springframework.context.support.AbstractApplicationContext.getMessage(AbstractApplicationContext.java:1276) at spring.webmvc@5.0.5.RELEASE/org.springframework.web.servlet.support.RequestContext.getMessage(RequestContext.java:725)

The error is caused by the following line which is using a custom ResourceBundle.Control.

https://github.com/spring-projects/spring-framework/blob/master/spring-context/src/main/java/org/springframework/context/support/ResourceBundleMessageSource.java#L223

Steps to reproduce:

Petclinic is the sample ported application to Spring Boot 2.0.1 and Java 9 module system.

1. Clone:

https://github.com/panga/spring-petclinic-java9modules

2. Build with JDK 10:

mvn clean package

3. Run application with module-path:

mvn exec:exec

Note: mvn spring-boot:run goal will execute in classpath mode, thus the erros doesn't happen.

4. Open browser with url:

http://localhost:8080/owners?lastName=test

5. Verify the stack trace in the console.

---

Affects: 5.0.5

Issue Links:

• ResourceBundleMessageSource should allow for custom PropertyResourceBundle subclass [SPR-12666] #17265 ResourceBundleMessageSource should allow for custom PropertyResourceBundle subclass

[spring-projects-issues]

Juergen Hoeller commented

I wasn't aware of that limitation. We'll revisit ResourceBundleMessageSource accordingly, ironically having to go back to the strategy that we had in Spring Framework 3.2 where we defensively handled ResourceBundle.Control for JDK 5 compatibility: For any settings that require such a custom control, we'll simply try its use and will catch UnsupportedOperationException, wrapping it into a friendly exception message that indicates no support for custom reloads and custom encodings in the chosen deployment layout. Otherwise we'll fall back to a plain ResourceBundle.getBundle call without a control which should also work on the module system then.

[spring-projects-issues]

Leonardo Zanivan commented

@juergen.hoeller thanks for your quick feedback!

Yes, that was a surprise to me too, I feel I'll hit more walls soon :D

[spring-projects-issues]

Leonardo Zanivan commented

Hi @juergen.hoeller,

I saw the change you did in commit d5aedac6db5ca6093b38d607bc2a60c59b93e9f9 and I think it need to be tweaked a little bit due to hardcoded "ISO-8859-1".

After JEP 226: UTF-8 Property Resource Bundles (http://openjdk.java.net/jeps/226) the default properties encoding is UTF-8 or configurable via system property.

My proposed solution snippet below:

 

if (JDK_VERSION >= 9){
 defaultJdkPropertiesEncoding = System.getProperty("java.util.PropertyResourceBundle.encoding", "UTF-8");
} else {
 defaultJdkPropertiesEncoding = "ISO-8859-1";
}

if ((defaultEncoding != null && !defaultJdkPropertiesEncoding.equals(defaultEncoding)) || !isFallbackToSystemLocale() || getCacheMillis() >= 0) {
...
} 

 

[spring-projects-issues]

Juergen Hoeller commented

For that particular check, we might simply reduce it to getDefaultEncoding() != null since there is no need for a user to explicitly redeclare the platform default encoding at ResourceBundleMessageSource level in the first place; you may simply leave the default for JDK 9+.

However, there is a harder problem waiting in the MessageSourceControl implementation where we enforce an ISO-8859-1 default if no encoding has been specified. For classpath scenarios, we should rather use JDK 9's default encoding there, ideally through PropertiesResourceBundle(InputStream)... but that's an unfortunately at odds with the loadBundle template method (#17265). We'll have to find a compromise for the latter since it is important to comply with JDK 9 there, and that template method won't be called in module path scenarios in any case.

[spring-projects-issues]

Leonardo Zanivan commented

I'm fine with this simplification if it's still compliant with JDK 8 and JDK 9 defaults.

Although, in that case Spring Boot MessageSource will be another source of problem because it always set UTF-8 and in this case the getDefaultEncoding() != null check will always fail when using Jigsaw modules.

https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/context/MessageSourceProperties.java#L46

I tested it here, my application fails because Spring Boot always set UTF-8 by default.

[spring-projects-issues]

Juergen Hoeller commented

It turns out that we actually have to use MessageSourceControl wherever possible in order to call our loadBundle template method even for standard scenarios, so we can't have a configuration-driven decision there in any case.

I've revised the approach, leniently taking the fallback with a plain ResourceBundle.getBundle lookup without ResourceBundle.Control handle after receiving an UnsupportedOperationException now, only logging an info-level message for it. In 5.1, we'll be more sophisticated about this, allowing to enforce the platform default encoding through explicitly setting defaultEncoding to null even on the classpath, whereas 5.0.6 will only have a rather simple fallback for making it work on the module path in a basic fashion.