Ruben Dijkstra opened SPR-16794 and commented

Optionally, a patch present: https://github.com/spring-projects/spring-framework/compare/master...Shredder121:message-source-support-formats

While looking to see if it was reported already, I stumbled upon #14252, which I believe has been fixed already? At least, I see a way to use customized MessageFormat instances now.

But I spotted we're only using the format function, which means we do not need the MessageFormat type, but can use Format instead.

Best regards,

Ruben

1 votes, 2 watchers

Comment From: spring-projects-issues

Ruben Dijkstra commented

I see there is also AbstractMessageSource#resolveCodeWithoutArguments and AbstractMessageSource#getMessageInternal, including subclasses where createMessageFormat is called directly, but the same applies, only format() is used.

This means the moving away from MessageFormat to support Format is trickier, but I would like to hear your opinion first.

Comment From: spring-projects-issues

Patrick Schmidt commented

I found this issue while researching how to use com.ibm.icu.text.MessageFormat instead of java.text.MessageFormat. Coincidentally, they both inherit from java.text.Format, so switching to that class would work for my use case. With relevant methods being final, there does not seem to be a way to wrap the ICU MessageFormat in the regular one, as a workaround. So I'd like to see this change implemented.

Comment From: Frettman

So, just for "fun" I downloaded the Spring Framework source and replaced java.text.MessageFormat with java.text.Format. 5 classes within org.springframework.context.support were affected, but I didn't have to touch any method calls. So on a technical level this change wouldn't be a problem for the Spring Framework itself. However, it does affect protected methods, so this would be a breaking change in the API and could cause compile errors for any 3rd party subclasses. Though I assume the fix would typically be as simple as replacing MessageFormat with Format. Anyway, if it is decided to pursue such a change (which I still hope), it might make sense to go with a new interface altogether (basically containing the one format-method currently used) instead of java.text.Format for even greater flexibility.

Comment From: jhoeller

Since this is just about an extension point for custom MessageSource implementations and the only case is the ICU4J project which we are not commonly seeing in practice, we do not intend to proceed with a change at that level. Compatibility with our existing protected signatures which have been there since 1.0 is more important.

Note that this is all about implementing the MessageSource SPI contract. Nothing prevents you from implementing the MessageSource interface directly without relying on our base classes. Admittedly this would mean quite a bit of duplicating/reimplementation of our common lookup algorithm.

If the argument is rather that you'd like to have a variant of ResourceBundleMessageSource but with ICU4J-style message formatting, this should be raised as a separate issue (or simply provided by an external extension library on GitHub). This does not imply that we have to break protected signatures in MessageSourceSupport and AbstractMessageSource.