Java 17 1Z0-829: Implementing Localization

Topic snapshot

Sample questions

These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.

Question 1

Topic: Implementing Localization

A Java 17 application uses this helper to read localized messages. The requirement is to return !key! only when a message key is missing from the selected bundle and its parents. If no bundle can be found for the base name, the application should fail fast.

String message(String baseName, Locale locale, String key) {
    try {
        var bundle = ResourceBundle.getBundle(baseName, locale);
        return bundle.getString(key);
    } catch (MissingResourceException e) {
        return "!" + key + "!";
    }
}

Which refactor is the best fix?

Options:

• A. Check whether getString(key) returns null before returning it.

• B. Move getBundle() outside the try; catch only getString() failures.

• C. Keep the catch around both calls and return the placeholder.

• D. Append the locale suffix to baseName before calling getBundle().

Best answer: B

Explanation: ResourceBundle.getBundle() and ResourceBundle.getString() can both throw MissingResourceException, but they mean different failures here. The catch block should cover only the acceptable failure: a missing key. Loading the bundle outside that catch preserves fail-fast behavior for a missing bundle.

The core issue is exception scope. ResourceBundle.getBundle(baseName, locale) throws MissingResourceException when no suitable bundle can be found. bundle.getString(key) throws the same exception when the key is absent from the bundle and its parent chain. Because the current try covers both calls, it hides a missing bundle by returning a placeholder. Refactor so bundle loading happens before the try, then catch MissingResourceException only around getString(key). The closest trap is treating all MissingResourceException cases the same, even though the scenario requires different behavior for missing bundles and missing keys.

• Broad catch fails because it masks missing bundle configuration instead of failing fast.
• Null check fails because getString(key) throws MissingResourceException for a missing key rather than returning null.
• Locale suffix naming bypasses normal ResourceBundle lookup rules and does not distinguish missing keys from missing bundles.

Question 2

Topic: Implementing Localization

A scheduling service stores meeting start times as Instant values in UTC. It must display each meeting using the user’s Locale for formatting conventions and the user’s ZoneId for local clock time. The current Java 17 code uses French formatting but still shows the UTC time.

record Prefs(Locale locale, ZoneId zone) {}

static String display(Instant start, Prefs p) {
    var fmt = DateTimeFormatter.ofLocalizedDateTime(FormatStyle.SHORT)
        .withLocale(p.locale());
    return fmt.format(start.atZone(ZoneId.of("UTC")));
}

Which refactor is the best fix?

Options:

• A. Use .withLocale(p.locale()).withZone(p.zone()) and format start.

• B. Use Locale.setDefault(p.locale()) before formatting in UTC.

• C. Convert start to LocalDateTime in UTC before formatting.

• D. Encode the zone ID into the locale language tag.

Best answer: A

Explanation: Locale and ZoneId solve different problems. The locale affects localized text and ordering, while the zone determines how an instant maps to a local date and time. Applying both to the DateTimeFormatter and formatting the Instant directly satisfies both requirements.

A Locale does not convert UTC instants into a user’s local clock time. It controls localized formatting details such as date order, separators, month names, and AM/PM text. A ZoneId controls temporal behavior by mapping the same Instant to a local date and time in a region. In this code, withLocale(p.locale()) affects presentation, but start.atZone(UTC) still produces a UTC ZonedDateTime. Adding withZone(p.zone()) lets the formatter apply the user’s zone when formatting the Instant.

The key takeaway is to use locale-sensitive APIs for presentation and zone-sensitive APIs for instant-to-local-time conversion.

• Default locale is a global setting and still does not convert the instant from UTC to the user’s zone.
• Locale tag zone confuses cultural formatting with temporal conversion and is not the right fix here.
• UTC LocalDateTime preserves the wrong clock time and also discards the instant’s time-zone context.

Question 3

Topic: Implementing Localization

An application throws this exception when loading a button label. Assume the shown resource files are on the classpath root and no other labels bundles exist. What is the best cause or next fix?

Locale locale = Locale.forLanguageTag("es-MX");
ResourceBundle labels = ResourceBundle.getBundle("labels", locale);
System.out.println(labels.getString("pay"));

labels.properties:
cancel=Cancel

labels_es.properties:
cancel=Cancelar

java.util.MissingResourceException: Can't find resource for bundle java.util.PropertyResourceBundle, key pay

Options:

• A. Create labels_es_MX.properties; regional bundles are mandatory.

• B. Replace es-MX with es_MX in forLanguageTag().

• C. Add pay to labels_es.properties or labels.properties.

• D. Use getObject("pay") instead of getString("pay").

Best answer: C

Explanation: ResourceBundle.getBundle() can find a less-specific bundle, so the missing labels_es_MX.properties file is not the immediate problem. The exception names key pay, which means a bundle was found but that key was not found in the loaded bundle or its parents.

For locale es-MX, resource bundle lookup can fall back from labels_es_MX.properties to labels_es.properties, then to labels.properties. In this case, labels_es.properties exists, so bundle lookup succeeds. The later call to getString("pay") searches the selected bundle and its parent chain, but both shown files contain only cancel. A missing key causes MissingResourceException, just as a missing bundle can, but the message identifies the missing key. Add pay to the Spanish file for a localized value or to the base file for a default fallback.

• Regional bundle requirement fails because es-MX can fall back to es and then the base bundle.
• Different accessor method fails because getObject() also throws MissingResourceException for a missing key.
• Language tag format fails because es-MX is the correct BCP 47 form for Locale.forLanguageTag().

Question 4

Topic: Implementing Localization

Given the following Java 17 program, what is the result?

import java.util.Locale;

public class TestLocale {
    public static void main(String[] args) {
        Locale a = Locale.US;
        Locale b = new Locale("en", "US");
        Locale c = Locale.forLanguageTag("en-US");
        Locale d = new Locale.Builder()
                .setLanguage("en")
                .setRegion("US")
                .build();
        Locale e = new Locale("en-US");

        System.out.print(a.equals(b) + " ");
        System.out.print(c.equals(d) + " ");
        System.out.print(e.getLanguage() + "/" + e.getCountry());
    }
}

Options:

• A. true true en-us/

• B. true false en-us/

• C. An IllformedLocaleException is thrown.

• D. true true en/US

Best answer: A

Explanation: Locale.US, new Locale("en", "US"), Locale.forLanguageTag("en-US"), and the builder with language en and region US all represent the same locale where applicable. The one-argument constructor does not parse a language tag, so "en-US" becomes the language field and the country remains empty.

Java provides several ways to create Locale values, but they do not all interpret strings the same way. Locale.forLanguageTag("en-US") parses a BCP 47 language tag into language en and region US. new Locale("en", "US"), Locale.US, and the builder using setLanguage("en") and setRegion("US") also represent that same language/region combination. However, new Locale("en-US") is the older one-argument constructor; it does not split the value at the hyphen. It stores the whole normalized value as the language, leaving the country empty. Therefore, the last printed part is en-us/.

• Tag parsing trap fails because only forLanguageTag parses en-US as language plus region.
• Builder mismatch trap fails because the builder values en and US produce the same locale as the language tag.
• Validation trap fails because the shown builder values are valid, and the old constructor does not throw for this string.

Question 5

Topic: Implementing Localization

Which statement about creating java.util.Locale values is correct in Java 17?

Options:

• A. Locale.forLanguageTag("en_US") is the standard form for US English.

• B. Locale.forLanguageTag("en-US") creates language en and country US.

• C. Locale.US must be passed to a builder before use.

• D. Locale.Builder uses setCountry("US") to set the region.

Best answer: B

Explanation: Java 17 supports several ways to create locales, including constants, constructors, builders, and BCP 47 language tags. For language tags, Locale.forLanguageTag("en-US") is the standard form and maps to language en with region/country US.

The core API rule is that Locale.forLanguageTag() expects a BCP 47 language tag. In that format, subtags are separated with hyphens, such as en-US or fr-CA, not underscores. A Locale.Builder can also create equivalent locales, but it uses methods such as setLanguage("en") and setRegion("US"). Constants such as Locale.US are already usable Locale instances.

The key takeaway is to distinguish Java locale constructors and constants from BCP 47 language-tag syntax.

• Underscore tag fails because en_US is not the standard BCP 47 language-tag form used by forLanguageTag().
• Builder method name fails because the builder method is setRegion(), not setCountry().
• Locale constant use fails because Locale.US is already a ready-to-use constant.

Question 6

Topic: Implementing Localization

An application stores an event start time as an Instant and must display it as a LONG localized date-time in Japanese for the Asia/Tokyo time zone, regardless of the JVM’s default locale or default time zone.

Instant start = Instant.parse("2025-03-10T01:15:00Z");

Which expression correctly applies Java SE 17’s localized DateTimeFormatter rules?

Options:

• A. DateTimeFormatter.ofPattern("LONG").withLocale(Locale.JAPAN).withZone(ZoneId.of("Asia/Tokyo")).format(start)

• B. DateTimeFormatter.ofLocalizedDateTime(FormatStyle.LONG).withZone(ZoneId.of("Asia/Tokyo")).format(start)

• C. DateTimeFormatter.ofLocalizedDateTime(FormatStyle.LONG).withLocale(Locale.JAPAN).withZone(ZoneId.of("Asia/Tokyo")).format(start)

• D. DateTimeFormatter.ofLocalizedDateTime(FormatStyle.LONG).withLocale(Locale.JAPAN).format(start)

Best answer: C

Explanation: Localized date-time formatters are created with ofLocalizedDateTime, then adjusted with withLocale for language and regional formatting. Because the temporal value is an Instant, a zone must also be supplied so calendar date and time fields can be derived.

DateTimeFormatter.ofLocalizedDateTime(FormatStyle.LONG) chooses a locale-sensitive date-time format style, but the locale is not fixed until withLocale(Locale.JAPAN) is applied. An Instant represents a point on the timeline and does not directly contain fields such as month, day, or hour in a calendar system. Supplying withZone(ZoneId.of("Asia/Tokyo")) lets the formatter convert the instant to local date-time fields for that zone. Using only a locale leaves the formatter without a zone for the instant, while using only a zone leaves the output dependent on the default locale.

• Missing zone fails because an Instant needs a formatter zone to produce localized calendar fields.
• Missing locale fails because the output would depend on the JVM’s default locale.
• Pattern string fails because "LONG" is not how localized styles are requested; ofLocalizedDateTime uses FormatStyle.

Question 7

Topic: Implementing Localization

Assume these resource files are on the runtime class path, and no other messages*.properties files or bundle classes exist:

messages_en.properties
title=Schedule
total=Total

messages_fr.properties
title=Planning

What is the result of running this Java 17 code?

import java.util.*;

public class Main {
  public static void main(String[] args) {
    Locale.setDefault(Locale.ENGLISH);
    var rb = ResourceBundle.getBundle("messages", Locale.FRANCE);
    System.out.print(rb.getString("title") + " ");
    System.out.print(rb.getString("total"));
  }
}

Options:

• A. It prints Schedule Total.

• B. It throws MissingResourceException before printing because messages_fr_FR.properties is missing.

• C. It prints Planning , then throws MissingResourceException for total.

• D. It prints Planning Total.

Best answer: C

Explanation: ResourceBundle first finds the best available bundle for the requested locale. Here Locale.FRANCE can use messages_fr.properties, so title resolves to Planning. The missing total key is not filled from the default English bundle once the French bundle has been found.

ResourceBundle.getBundle("messages", Locale.FRANCE) searches locale candidates such as messages_fr_FR and then messages_fr. Since messages_fr.properties exists, that bundle is used. For getString("title"), the key exists and Planning is printed. For getString("total"), Java searches the selected bundle and its parent chain, such as a base messages.properties file if one exists. The default locale bundle messages_en.properties is not used as a per-key fallback after a requested-locale bundle has already been found. Because no base bundle exists and total is absent from the French bundle, getString("total") throws MissingResourceException after the first print call.

• Default-locale fallback fails because messages_en.properties is not consulted for individual missing keys after messages_fr.properties is selected.
• English output fails because the French bundle exists and supplies the title key.
• Missing regional file fails because messages_fr.properties is an acceptable fallback for Locale.FRANCE.

Question 8

Topic: Implementing Localization

An application retrieves a French message pattern and formats it with MessageFormat. The file name must appear before the user name in French.

Object[] msgArgs = {"Ana", "rapport.csv"};
String pattern = "Le fichier {1} de l'utilisateur {0} est prêt";
System.out.println(MessageFormat.format(pattern, msgArgs));

Actual output:

Le fichier rapport.csv de lutilisateur {0} est prêt

Desired output:

Le fichier rapport.csv de l'utilisateur Ana est prêt

Which replacement pattern is the best fix?

Options:

• A. Le fichier {1} de l'''utilisateur {0} est prêt

• B. Le fichier {0} de l''utilisateur {1} est prêt

• C. Le fichier {1} de l''utilisateur {0} est prêt

• D. Le fichier {1} de l\'utilisateur {0} est prêt

Best answer: C

Explanation: In MessageFormat, a single apostrophe starts or ends a quoted literal. The French apostrophe after l must be written as two apostrophes, while the numbered placeholders keep the file name before the user name.

MessageFormat patterns use numbered placeholders such as {0} and {1} to select arguments by index. Single quotes quote literal pattern text, so the apostrophe in l'utilisateur causes the rest of the text to be treated as literal, leaving {0} unformatted and removing the apostrophe. A literal apostrophe must be written as ''. Placeholder numbers are argument indexes, not reading order: {0} is "Ana" and {1} is "rapport.csv". This lets a localized pattern put {1} before {0} without changing the argument array.

• Swapped placeholders changes the meaning by formatting Ana as the file and rapport.csv as the user.
• Backslash escaping fails because MessageFormat uses single quotes for quoting, not \.
• Triple quotes produce one literal apostrophe and then quote the rest, so {0} remains literal.

Question 9

Topic: Implementing Localization

An app stores a localized pattern in messages_fr.properties and formats it as shown. The required output is exactly 3 fichiers pour l'utilisateur Mina. Which property declaration should be used?

var pattern = bundle.getString("upload");
var mf = new MessageFormat(pattern, Locale.FRANCE);
System.out.println(mf.format(new Object[] {"Mina", 3}));

Options:

• A. upload={1} fichiers pour l'utilisateur {0}.

• B. upload={1} fichiers pour l''utilisateur {1}.

• C. upload={1} fichiers pour l''utilisateur {0}.

• D. upload={0} fichiers pour l''utilisateur {1}.

Best answer: C

Explanation: MessageFormat placeholders are zero-based argument indexes and may appear in any order. For localized text, the count can use {1} before the user name {0}. A literal apostrophe in a MessageFormat pattern must be written as two single quotes.

MessageFormat treats {0}, {1}, and similar tokens as references to the argument array passed to format. Here argument 0 is "Mina" and argument 1 is 3, so the French pattern must put {1} before the noun phrase and {0} after utilisateur. Single quotes have special meaning in MessageFormat patterns because they quote literal text. To output an actual apostrophe in l'utilisateur, the pattern must contain l''utilisateur.

A single apostrophe is not an escape character for itself; it starts quoted text and can prevent placeholders from being interpreted.

• Swapped arguments fails because {0} would print Mina where the count must appear.
• Single apostrophe fails because MessageFormat treats it as a quoting delimiter, not as a literal apostrophe.
• Repeated count fails because using {1} in both positions prints the file count twice.

Question 10

Topic: Implementing Localization

In Java 17, a service formats an Instant for users with a DateTimeFormatter that has both withLocale(...) and withZone(...) configured. Which rule correctly distinguishes what these two settings affect?

Options:

• A. Both Locale and ZoneId are ignored because Instant stores local time.

• B. Changing Locale changes the hour or date when the zone stays unchanged.

• C. Locale controls presentation conventions; ZoneId controls the local temporal value.

• D. Locale controls the time-zone offset; ZoneId controls only translated zone names.

Best answer: C

Explanation: Locale is about how values are presented, such as language, symbols, and date/time formatting conventions. ZoneId is about temporal interpretation of an instant, determining the local date, time, and offset used for formatting.

For Java 17 date-time formatting, Locale and ZoneId solve different problems. A Locale affects localized output, such as month names, day names, decimal symbols, and date/time pattern conventions. A ZoneId affects the actual local temporal fields produced from an Instant, because an instant is a point on the timeline and must be viewed in a zone to become a local date and time.

Changing the locale may change how the same local value is displayed. Changing the zone may change the hour, date, or offset displayed.

• Offset by locale is wrong because a country or language locale does not select the time-zone offset for an Instant.
• Ignored settings is wrong because DateTimeFormatter can use both locale and zone when formatting temporal values.
• Locale changes time is wrong because locale changes presentation, not the underlying local temporal conversion.

Continue with full practice

Use the Java 17 1Z0-829 Practice Test page for the full IT Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Try Java 17 1Z0-829 on Web View Java 17 1Z0-829 Practice Test

Related focused pages

• Free Java 17 1Z0-829 Full-Length Practice Exam
• Core Value Types
• Controlling Program Flow
• Object-Oriented Java
• Handling Exceptions
• Working with Arrays and Collections
• Streams and Lambdas
• Packaging and Modules
• Managing Concurrent Code Execution
• Using Java I/O API
• Accessing Databases Using JDBC
• Logging and Annotations

Free review resource

Read the Java 17 1Z0-829 Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.