No, because in tryBundle, a new string is created with basename +
locale. It is that new string that is put in the cache, not just the
basename.
For example, say you're looking for a resource "MyResource" with
locale en_US. If it is found, then the result is cached with a key
created from MyResource_en_US, not MyResource.
Never the less, I'd be interested to know where the 2 minute speedup
came from, and if there is anything we can do to improve
ResourceBundle without breaking its semantics. Does Tomcat request
the same bundle baseName for many different locales?
It is when it loads struts. It is looking for a resource
ApplicationProperties with all the locales classpath has. With the
current implementation of ResourceBundle, looking for all resources
takes a real long time. Here's an example :
1) You're in getBundle looking for resource ApplicationProperties with
locale AA_aa
2) It's not in the cache, so you go into tryBundle
3) In tryBundle, you don't find ApplicationProperties_AA_aa
4) In tryBundle you find ApplicationProperties_AA so you return it
5) In getBundle you cache ApplicationProperties_AA_aa with the result
(ApplicationProperties_AA is not cached)
6) In the next getBundle, you're looking for ApplicationProperties
with locale AA...
The patch improves the researches by caching ApplicationProperties_AA.
Even better, in tryBundle when a result is found for a resource, we
could cache all intermediary resources we were looking for. For
example if we were looking for ApplicationProperties_AA_aa, and
finally found a result for ApplicationProperties (with no locale), we
could cache ApplicationProperties, ApplicationProperties_AA_aa, and
ApplicationProperties_AA with that same result.
I haven't done this greater optimisation, as i'm not sure of the
correctness of the patch regarding "the most specialized bundle" in
tryBundle.