Localization. How to indicate where resource bundle property files are located?

I am using IntelliJ and here is the location of my Resource bundle and property files (see screenshot).
When I run this code, I get a MissingResourceException.

package boyarsky_ch11_exceptions_localization; import java.util.Locale; import java.util.ResourceBundle; public class Toothbrush {    static void brush() {        Locale.setDefault(new Locale.Builder()                .setLanguage("es")                .setRegion("MX").build());        var rb = ResourceBundle.getBundle("toothbrush",                new Locale("fr"));        var a = rb.getString("color");        var b = rb.getString("type");        System.out.print(a + " " + b);    }    public static void main(String[] args) {        brush();    } }

Exception in thread "main" java.util.MissingResourceException: Can't find bundle for base name toothbrush, locale fr at java.base/java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:2045) at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1683) at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1586) at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1549) at java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:932) at boyarsky_ch11_exceptions_localization.Toothbrush.brush(Toothbrush.java:11) at boyarsky_ch11_exceptions_localization.Toothbrush.main(Toothbrush.java:18)

I needed to specify the package also. This fixed the error.

       var rb = ResourceBundle.getBundle("boyarsky_ch11_exceptions_localization.toothbrush",

Trying to solve the question, I don't understand why the property file for es wasn't found.
es_MX is the default locale.

The output is

violette generic

I expected

violette lujoso

The question is:

tb864615.OCPJAVASE17PT.c14.046
Given the following three property files, what does the following method output?

toothbrush.properties
color=purple
type=generic

toothbrush_es.properties
color=morado
type=lujoso

toothbrush_fr.properties
color=violette

void brush() {   Locale.setDefault(new Locale.Builder()      .setLanguage("es")      .setRegion("MX").build());   var rb = ResourceBundle.getBundle("toothbrush",      new Locale("fr"));   var a = rb.getString("color");   var b = rb.getString("type");   System.out.print(a + " " + b); }

       var rb = ResourceBundle.getBundle("toothbrush",                new Locale("fr"));

stacktrace wrote:
Exception in thread "main" java.util.MissingResourceException: Can't find bundle for base name toothbrush, locale fr

So as I read it, you're attempting to read from toothbrush_fr.properties with default values coming from toothbrush.properties. You are overriding the Locale, so the fact that you set the default locale to es_MX shouldn't matter here.

Tim Holloway wrote: default values coming from toothbrush.properties. You are overriding the Locale, so the fact that you set the default locale to es_MX shouldn't matter here.

I am finding it hard to understand this. If default locale is set to es_MX then shouldn't it take type from there?

P.S. the exception is not related to this - it was from my not specifying the package.

I have not read the docs in a long time, but no, I'm pretty sure that the arrangement is that you can set up a chain of locales to search, but the master bundle that is referenced when a key cannot be found in any other bundle in the chin is simply "basename.properties" and not a local-specific "basename_xx_YY..properties".

The thing I wonder about more is that your bundle name is "boyarsky_ch11_exceptions_localization.toothbrush". Because I was pretty sure that bundle paths were done the same way as other Java package resources, so a more likely bundle specification would be "boyarsky.ch11.exceptions.localization.toothbrush".

I haven't looked at the docs for a very very long time either, neither have I had to deal with a complex setup like that, but the posted code looks very much like the example in Baeldung's ResourceBundle tutorial. In which case I think Anil is correct.

I'm assuming that the code at the beginning does set the default locale... Oops! I just looked at it for the fifth or sixth time. It does indeed set the default locale. Just not to es_MX, that is. That explains the book's answer, which is correct.

No, wait a minute, I'm still confused by Locale terminology. The Locale.Builder documentation talks about "language" and "region" and Locale talks about "language" and "country". For example there's a Locale called CANADA_FRENCH whose name is "fr-CA". The meaning of the thing is "French as used in Canada". Likewise "es-MX" is "Spanish as used in Mexico" and "es" is "Spanish default usage".

So the code from the book does actually produce the "es-MX" Locale which should work the way that Anil says it should work. That's my opinion so far. Waiting for somebody else to explain why we're wrong.

... (later) ... After spending a while to figure out where to put the property files, I ran the code and got the same output as Anil.

Paul Clapham wrote:
So the code from the book does actually produce the "es-MX" Locale

Here is the output showing the default locale set
       var a = rb.getString("color");        var b = rb.getString("type");        System.out.println(a + " " + b);        System.out.println("Locale.getDefault: " + Locale.getDefault());

violette generic
Locale.getDefault: es_MX

From my understanding, it should go to the default locale if it cannot find the exact-match property file.
So I don't know why it doesn't.

Anil Philip wrote:From my understanding, it should go to the default locale if it cannot find the exact-match property file.

That's what the tutorial I linked to says too. (I'm pretty sure it says that.)

So I don't know why it doesn't.

Me neither. Although I've never written code where the default locale is involved in the decision process.

Paul Clapham wrote:That's what the tutorial I linked to says too. (I'm pretty sure it says that.)

Here is what Boyarsky-Selikoff says are the steps followed:

1) Look for the resource bundle for the requested locale, followed by the one for the default locale.
2) For each locale, check the language/country, followed by just the language.
3) Use the default resource bundle if no matching locale can be found.

Item #1: Yes, Baeldung seems to confirm it's "package.path.toothbbrush.properties", not "package_path.toothbrush.properties".

Item #2. The Locale definition in the example sets the default Locale for the entire JVM, not just the Bundle. So, if I'm correct, an unqualified getBundle("package.path.toothbbrush.properties") would concatenate package.path.toothbrush_es_MX.properties, package.path.toothbrush_es.properties and finally package.path.toothbrush.properties, searching them in that order until the named property is resolved (fallback resources).

HOEVER, since Locale "fr" was given on the getBundle, the DEFAULT language/region is overridden by the SPECIFIED language/region, giving us a concatenation of package.path.toothbrush_fr.properties and package.path.toothbrush.properties.

Final note: Don't confuse the default locale with the default bundle. The default bundle is the one with no locale qualifiers in its filename.

Anil Philip wrote:1) Look for the resource bundle for the requested locale, followed by the one for the default locale.

Is it possible that because there isn't a property file for "es-MX", which is the default locale, therefore the "es" property file isn't looked at?

You could test that by adding an es-MX property file to your setup.

Paul Clapham wrote:You could test that by adding an es-MX property file to your setup.

The output remains the same. See screenshot.

violette generic
Locale.getDefault: es_MX

toothbrush_es_MX.properties

color=dazzle
type=bling

Anil Philip wrote:The output remains the same. See screenshot.

As I mostly expected.

If I was you I'd leave this one for now and move on. It could be errata, after all. Or it could be some picky thing that we haven't noticed.

You seem confused what "default locale" really means.

"Default locale" does NOT mean "Use this locale if you can't find a resource for the explicitly specified locale".

"Default locale" means "Use this locale if you don't explicitly specify a locale".

You explicitly specified a locale for your resource bundle ("fr"), so the default locale is no longer relevant.

You're asking toothbrush_fr for the "color" and "type" strings. It contains one for "color", so it returns "violette". It does NOT contain a string for "type", so it returns the value from its parent bundle (which is the root bundle): "generic".

The parent bundle of toothbrush_es_MX is indeed toothbrush_es, but you never asked toothbrush_es_MX for a string, because you explicitly specified the locale "fr".

Paul Clapham wrote:No, wait a minute, I'm still confused by Locale terminology. The Locale.Builder documentation talks about "language" and "region" and Locale talks about "language" and "country". For example there's a Locale called CANADA_FRENCH whose name is "fr-CA". The meaning of the thing is "French as used in Canada". Likewise "es-MX" is "Spanish as used in Mexico" and "es" is "Spanish default usage".

Region and country should be treated interchanably in the docs. Per the Locale doc

country (region)
ISO 3166 alpha-2 country code or UN M.49 numeric-3 area code. You can find a full list of valid country and region codes in the IANA Language Subtag Registry (search for "Type: region"). The country (region) field is case insensitive, but Locale always canonicalizes to upper case.
Well-formed country/region values have the form [a-zA-Z]{2} | [0-9]{3}
Example: "US" (United States), "FR" (France), "029" (Caribbean)

Region is more generic so my guess is they started using region after writing the original code. A region could be something that isn't a country (like the two examples you gave)

The output of "violette generic" is correct.

Here's the explanation in the book

Java starts out by looking for a properties file with the requested locale. In this case, the
requested locale is the fr language, which it finds with toothbrush_fr.properties.
For this reason, the default locale of es_MX is ignored, and the first value for color printed
is violette. Next, it looks for a value for type property. Since it doesn’t find it in the first
properties file, it checks the default toothbrush.properties, where it does find it, and
prints generic. For these reasons, option B is correct.

And to use different words since Anil is confused, there's two concepts at play and this question tests both.

Concept 1 - Finding the locale to use
The locale search order is what you quoted. Look for the requested locale followed by the one for the default with language/region and then just language, falling thru to default. This results in finding toothbrush_fr.properties since the requested local is "fr" (French.)

At this point, you remember toothbrush_fr.properties and stop thinking about the locales. They aren't used anymore

Concept 2 - Getting properties
Once you have the property file, Java only looks in it (and more generic) ones. Since "color" is found in the fr file, violette is printed. For "type", it is not found in the fr file. So Java looks up the hierarchy and uses "generic" from the default/parent.

The "parent" relationship is dropping the region/country if present and then dropping the language if present. In concept 2, it does not look at alternate locales because it found one. This makes sense as  you wouldn't want your user documentation to be a mix of French and Spanish!

Stephan van Hulst wrote:You seem confused what "default locale" really means.

Well, then consider what Boyarsky-Selikoff are saying. Look at step 3:

Java handles the logic of picking the best available resource bundle for a given key. It tries to find the most specific value. Table 11.11 shows what Java goes through when asked for resource bundle Zoo with the locale new Locale("fr", "FR") when the default locale is U.S. English.

TABLE 11.11 Picking a resource bundle for French/France with default locale English/US

see screenshot

As another way of remembering the order of Table 11.11, learn these steps:

Look for the resource bundle for the requested locale, followed by the one for the default locale.
For each locale, check the language/country, followed by just the language.
Use the default resource bundle if no matching locale can be found.

Jeanne Boyarsky wrote:
And to use different words since Anil is confused,

Please see the screenshot of the table from the book. Step 2 and Step 3.
It looks for fr and then goes to the default en_US.

I see. Yes, that's incorrect.

Either steps 1, 2, 5, 6 are taken if you explicitly specify a locale, or steps 3, 4, 5, 6 are taken if you don't explicitly specify a locale.

Anil Philip wrote:

Jeanne Boyarsky wrote:
And to use different words since Anil is confused,

Please see the screenshot of the table from the book. Step 2 and Step 3.
It looks for fr and then goes to the default en_US.

I don't see how it is incorrect. We are talking about the "Finding the Locale to use step". If fr isn't found, it goes on looking. But in the question we are discussing in this thread, fr is used. So it doesn't go on any further looking up a locale. If found the fr one so now knows to use that.

Stephan van Hulst wrote:I see. Yes, that's incorrect.

Either steps 1, 2, 5, 6 are taken if you explicitly specify a locale, or steps 3, 4, 5, 6 are taken if you don't explicitly specify a locale.

I still think the table is correct. Try deleting the "fr" file from your file system and running the same example. It finds the spanish one.

The locale is specified but there are no matching files so Java goes on to the default locale.

I double checked it, you're correct.

That's extremely disappointing behavior. I can't really think of a good use case to switch to a different locale (even if it IS the default locale) if my resource bundle can't be found. Just use the root bundle instead.

That just makes me want to set the default locale to some obscure locale that I know will never be used in my application.

Jeanne Boyarsky wrote:The locale is specified but there are no matching files so Java goes on to the default locale.

Jeanne Boyarsky wrote:Next, it looks for a value for type property. Since it doesn’t find it in the first
properties file, it checks the default toothbrush.properties, where it does find it, and
prints generic. For these reasons, option B is correct.

But the book does not say that now it starts looking for properties, and it just shoots up to the generic toothbrush.properties.

Stephan van Hulst wrote:I double checked it, you're correct.

That's extremely disappointing behavior.

That just makes me want to set the default locale to some obscure locale that I know will never be used in my application.

I see that Anil wasn't the only one who was confused!

Anil Philip wrote:

Jeanne Boyarsky wrote:The locale is specified but there are no matching files so Java goes on to the default locale.

Jeanne Boyarsky wrote:Next, it looks for a value for type property. Since it doesn’t find it in the first
properties file, it checks the default toothbrush.properties, where it does find it, and
prints generic. For these reasons, option B is correct.

But the book does not say that now it starts looking for properties, and it just shoots up to the generic toothbrush.properties.

The toothbrush thing is an explanation for a question though. It's providing a summary of the reasons, not explaining as if the study guide hasn't been read. The chapter part does explain it more thoroughly (ex: the table)

Jeanne Boyarsky wrote:The chapter part does explain it more thoroughly (ex: the table)

In the explanation of the following table 11.12

The JVM will provide data from en_US only if there is no matching fr_FR or fr resource bundle. If it finds a fr_FR or fr resource bundle, then only those bundles, along with the default bundle, will be used.

what does "along with the default bundle" mean? I thought the default bundle is excluded since fr has been found.

No. You are once again confusing "default bundle" and "default locale". To avoid confusion, I prefer to say "root bundle" instead of "default bundle".

There are two separate phases that you need to consider in isolation from each other. Phase one is getting the resource bundle. Phase two is getting a string from the found resource bundle.

First, we get a resource bundle. This works according to the steps in table from the screenshot. Let's say you've explicitly specified the locale "fr-FR", so the application starts by looking for "toothbrush_fr_FR.properties". If that file doesn't exist, then it continues by looking for "toothbrush_fr.properties". If that file doesn't exist either, it continues by looking for the file that matches the default locale, which would be "toothbrush_es_MX.properties" (using your original example). If that file doesn't exist, it continues by looking for "toothbrush_es.properties". Finally, if that file doesn't exist either, it falls back on the root bundle "toothbrush.properties".

Let's assume that the file "toothbrush_fr.properties" exists and has been found by the call to ResourceBundle.getBundle(). You are now completely done with the default locale and can erase it from your mind. However, you must not forget about the root bundle, because it is still used in phase two!

We are now in phase two: getting a string from the resource bundle.

If a string can't be found in a resource bundle, the call is delegated to the bundle's parent bundle. The parent bundle of toothbrush_fr.properties is the root bundle "toothbrush.properties". Once again, the default locale plays absolutely no role in this phase. If "toothbrush_fr.properties" exists, then it will NEVER delegate to "toothbrush_es.properties", even if the default locale is "es-MX".

Stephan van Hulst wrote:No. You are once again confusing "default bundle" and "default locale". To avoid confusion, I prefer to say "root bundle" instead of "default bundle".

Which is what many of us have done. Looking at the Baeldung tutorial, they do use the correct terminology but then steer us directly into this confusion.

It's the same with Table 11.11, posted earlier. It describes the actual process correctly but it very easily leads the incautious reader into incorrect assumptions.

Stephan van Hulst wrote:
There are two separate phases that you need to consider in isolation from each other. Phase one is getting the resource bundle. Phase two is getting a string from the found resource bundle.

Clear explanation. Thank you!
@Jeanne Can you please include this explanation in your book?
After Table 11.11 example showing how to get the Resource Bundle for the Locale, you also listed the steps to get it. This was phase 1 or concept 1 (to use your term).
It will be good to also list the steps showing how to get the key from the property files. This was missing for phase 2 or concept 2.

Couple of remarks here. The language/region think isn't unique or new to bundles. You also use it, for example, to indicate keyboard classes when installing Linux for distros that set up locale at install time. There's actually an RFC for those designators, I believe.

It's not technically correct to talk about Bundle "phases". If memory serves, Bundles are based on Properties, and Properties are chainable. So "getBundle" is actually loading in the applicable property files all at once and realizing each file's contents as a loaded Properties object chained to the next property until you get down to the base property, which chains to nothing. When you do a "get" on a Property, the property table is searched first, then, if the key isn't found there, the chained Property is searched, and so forth.

The Bundle Properties are not magic, so it's also perfectly legal to front them with additional layers of Properties inside the app if you find it useful to do so.

The Bundle property loading runs from most specific to least specific, so "en_US" is the top Property object, followed by "en", followed by default. And again, "default" means ROOT, not default locale. If you ask for a Bundle with specific Locale, that overrides the default locale.

It is not required to have a region-specific Bundle property. You could have a "toothbrush_en" and a "toothbrush" (root) and the English could bloody well learn how to spell "aluminum" instead of supplying an "en_GB" layer.

I've made a note to see if we want to change anything next time we look at it.

Here is a javadoc page for the default Resource Bundle Search and Loading Strategy.

Ira Go wrote:Here is a javadoc page for the default Resource Bundle Search and Loading Strategy.

Thank you