Clarify AbstractResourceBasedMessageSource.setCacheMillis vs java.util.ResourceBundle

[destan]

Affects: 4.x, 5.x

---

In Javadoc of org.springframework.context.support.AbstractResourceBasedMessageSource#setCacheMillis
it says:

Default is "-1", indicating to cache forever (just like java.util.ResourceBundle).

However -1 in java.util.ResourceBundle is TTL_DONT_CACHE and its effect is not cache forever.

It should be TTL_NO_EXPIRATION_CONTROL = -2 to have the cache forever effect.

Hence I think implementation of org.springframework.context.support.ResourceBundleMessageSource#getResourceBundle is inconsistent with java.util.ResourceBundle.

it caches forever for any value less than 0. In order to be consistent with java.util.ResourceBundle it should be as follows

if (getCacheMillis() >= -1) {
	return doGetBundle(basename, locale);
}
else {
	// Cache forever...
}

and call doGetBundle for TTL_DONT_CACHE = -1 as well.

@jhoeller what do you think about it?

[jhoeller]

That documentation comment actually refers to the default behavior of java.util.ResourceBundle, not to its time-to-live constants. That comment even predates the introduction of time-to-live support in java.util.ResourceBundle itself. From a ResourceBundleMessageSource and in particular from a AbstractResourceBasedMessageSource perspective, compatibility with those JDK constants is not a goal to begin with; the cacheMillis and cacheSeconds properties have their own rules there, following Spring conventions.

I'll revise the documentation accordingly, explicitly mentioning the default behavior reference.