Given the contents: MessageBundle_en.properties file: message=Hello MessageBundle_en.properties file: message=Hello there MessageBundle_US.properties file: message=Howdy…

Question

Options

• AMessageBundle_en_US.properties
• BMessageBundle_en.properties
• CMessageBundle_fr_FR.properties
• DMessageBundle_US.properties
• EMessageBundle.properties

• A
  13% (6)
• B
  79% (38)
• C
  2% (1)
• D
  2% (1)
• E
  4% (2)

Explanation

ResourceBundle.getBundle() searches for resources by building a candidate list from the requested locale first, then the default locale, then the base bundle. Here, the effective lookup locale is Locale("en") (built via new Locale.Builder().setLanguage("en").build()), so the search order is: MessageBundle_en → MessageBundle_fr_FR → MessageBundle_fr → MessageBundle. Since MessageBundle_en.properties exists and matches at step one, it wins - no further candidates are tried.

Why the distractors are wrong:

• A (MessageBundle_en_US.properties) - the "en" locale has no country component, so en_US is never a candidate for a plain en lookup.
• C (MessageBundle_fr_FR.properties) - the French locale is the default, not the requested locale; it only enters the search as a fallback if no "en" resources are found.
• D (MessageBundle_US.properties) - US alone is a country without a language prefix; it is never a valid candidate in the lookup chain.
• E (MessageBundle.properties) - the base bundle is the last resort; the algorithm finds MessageBundle_en before reaching it.

Memory tip: Think of ResourceBundle search as "requested locale → default locale → base," going from most-specific to least-specific within each tier. The first file that exists wins, so a matching _language file beats any default-locale or base-bundle file.

No community discussion yet for this question.