Free Java 21 1Z0-830 Practice Questions: Implementing Localization

Topic snapshot

Sample questions

These are original IT Mastery practice questions aligned to this topic area. They are not official Oracle questions, copied live-exam content, or exam dumps. Use them to preview question style and explanation depth before continuing with topic drills, mixed sets, and timed mocks in IT Mastery.

Question 1

Topic: Implementing Localization

Assume Locale.US is passed explicitly to each NumberFormat factory method and no custom pattern is applied. Which statement about NumberFormat is correct in Java 21?

Options:

• A. Parsing currency text with getCurrencyInstance produces a Currency.

• B. Parsing 25% with getPercentInstance(Locale.US) produces 0.25.

• C. parse(String) must consume all characters or throw ParseException.

• D. An explicit Locale.US formatter uses the current default locale.

Best answer: B

Explanation: NumberFormat instances are locale-sensitive and style-sensitive. A percent instance treats the displayed percent value as scaled by 100, so parsing 25% yields the underlying numeric value 0.25.

NumberFormat.getPercentInstance(locale) creates a formatter whose percent style applies a multiplier of 100 for display and the inverse operation for parsing. With Locale.US, formatting 0.25 can display as 25%, and parsing 25% returns a Number whose numeric value is 0.25. Passing Locale.US explicitly fixes the formatter’s locale for that instance; it does not depend on the current default locale. Also, NumberFormat.parse(String) may parse a valid prefix rather than requiring the whole string to be consumed. Use ParsePosition when complete consumption must be verified.

• Currency object confusion fails because parsing returns a Number, not a Currency instance.
• Default locale confusion fails because the factory method was given Locale.US explicitly.
• Full input parsing fails because parse(String) may stop after a parseable prefix instead of throwing.

Question 2

Topic: Implementing Localization

An application stores audit events as Instant values. A report must format each event using German locale conventions while showing wall-clock time in America/New_York. The server’s default FORMAT locale and default time zone must not affect the result.

Given:

Instant stamp = Instant.parse("2025-03-15T15:30:00Z");
DateTimeFormatter f =
    DateTimeFormatter.ofLocalizedDateTime(FormatStyle.MEDIUM);

Which expression meets the requirement?

Options:

• A. f.withLocale(Locale.GERMANY).withZone(ZoneId.of("America/New_York")).format(stamp)

• B. f.withLocale(Locale.GERMANY).withZone(ZoneId.of("Europe/Berlin")).format(stamp)

• C. f.withLocale(Locale.GERMANY).format(stamp)

• D. f.withLocale(Locale.US).withZone(ZoneId.of("America/New_York")).format(stamp)

Best answer: A

Explanation: Locale and time zone affect different parts of temporal output. The locale controls localized formatting conventions, while the ZoneId controls how an Instant is converted into local date and time fields.

DateTimeFormatter.withLocale() changes locale-sensitive presentation, such as localized patterns and text. It does not choose a geographic time zone. DateTimeFormatter.withZone() supplies the zone used when formatting a temporal value such as an Instant, which has no local date or time fields by itself. For this requirement, the formatter must use Locale.GERMANY for German conventions and ZoneId.of("America/New_York") for the wall-clock time.

Setting a German locale alone is not enough, and using a German-region time zone would change the temporal result rather than just the presentation style.

• Berlin zone uses German-style formatting but converts the instant to Berlin wall-clock time, not New York time.
• US locale uses the requested New York zone but does not apply German locale conventions.
• Locale only leaves the Instant without a zone for localized date-time formatting, so it does not satisfy the requirement.

Question 3

Topic: Implementing Localization

In a Java 21 application, a localized message is formatted with java.text.MessageFormat. Which statement correctly describes placeholders, quoting, and argument ordering in a MessageFormat pattern?

Options:

• A. {n} selects zero-based argument n; indexes may repeat or appear out of order, and '' emits one quote.

• B. {n} selects the nth placeholder occurrence; indexes must be consecutive, and quotes are printed unchanged.

• C. {n} is resolved by placeholder order; literal braces are written with {{ and }}.

• D. {n} indexes are one-based; a single quote is escaped with a backslash.

Best answer: A

Explanation: MessageFormat uses numeric argument indexes, not placeholder position, to choose values from the supplied arguments. Those indexes are zero-based and can be repeated or arranged for each locale. Single quotes control quoting, and doubled single quotes produce one literal quote.

In java.text.MessageFormat, a placeholder such as {2} refers to argument index 2 from the argument array, so localized patterns can reorder values without changing the calling code. The same index can appear more than once, and indexes do not need to follow left-to-right order. Single quotes are special in the pattern: they quote literal pattern text, such as braces, and '' represents one literal apostrophe. This differs from APIs that use occurrence order or doubled braces for escaping.

• Placeholder occurrence fails because {n} names an argument index, not the nth placeholder in the pattern.
• Doubled braces fails because MessageFormat uses single-quote quoting for literal pattern text, not {{ and }}.
• Backslash escape fails because a literal apostrophe is written as '', not with \'.

Question 4

Topic: Implementing Localization

What is the output of this Java 21 program?

import java.text.MessageFormat;
import java.util.Locale;

public class Demo {
    public static void main(String[] args) {
        var pattern = "User {1} set '{0}' to ''{2}''";
        var mf = new MessageFormat(pattern, Locale.US);
        System.out.println(mf.format(new Object[] {"mode", "Ari", "debug"}));
    }
}

Options:

• A. User Ari set mode to 'debug'

• B. User mode set Ari to 'debug'

• C. User Ari set {0} to 'debug'

• D. The code throws IllegalArgumentException.

Best answer: C

Explanation: MessageFormat uses numeric placeholders to choose arguments by index, not by their order in the pattern. Single quotes quote pattern text, while doubled single quotes produce a literal apostrophe, so only {1} and {2} are substituted here.

In a MessageFormat pattern, {0}, {1}, and similar placeholders refer to argument array positions. A single quote starts or ends quoted literal text, so '{0}' is printed as the literal text {0} rather than being replaced by mode. Two consecutive single quotes represent one literal apostrophe, so ''{2}'' becomes a single quote, the formatted value of argument 2, and another single quote.

The key takeaway is that placeholder order and argument index are separate, and quoting controls whether braces are interpreted as placeholders.

• Quoted placeholder fails for the option replacing {0} with mode because single quotes make {0} literal text.
• Argument order fails for the option using mode as the user because {1} selects the second argument, Ari.
• Exception claim fails because the pattern is valid; quoted text and doubled apostrophes are legal MessageFormat syntax.

Question 5

Topic: Implementing Localization

A reporting service must print a French full-style date and time, including the French time-zone name. This Java 21 code compiles but fails at runtime while formatting:

Locale locale = Locale.FRANCE;
LocalDateTime orderTime = LocalDateTime.of(2025, 8, 20, 14, 30);

DateTimeFormatter fmt = DateTimeFormatter
        .ofLocalizedDateTime(FormatStyle.FULL)
        .withLocale(locale);

System.out.println(fmt.format(orderTime));

What is the best next fix?

Options:

• A. Format orderTime.toString() with the formatter.

• B. Use DateTimeFormatter.ISO_LOCAL_DATE_TIME instead.

• C. Provide a ZoneId, such as formatting orderTime.atZone(...).

• D. Replace Locale.FRANCE with Locale.FRENCH.

Best answer: C

Explanation: The formatter is locale-aware, but the selected full date-time style for France includes time-zone text. LocalDateTime contains only a date and a time, so it cannot supply a zone. Use a ZonedDateTime or a formatter override zone when full localized date-time output must include a time zone.

DateTimeFormatter.ofLocalizedDateTime(FormatStyle.FULL) chooses a locale-specific pattern after withLocale(Locale.FRANCE) is applied. For this French full date-time output, the pattern includes a time-zone name, but LocalDateTime has no ZoneId or offset. Attach the intended zone before formatting, for example with orderTime.atZone(ZoneId.of("Europe/Paris")), or otherwise supply a formatter zone override when appropriate. The issue is missing temporal information, not an invalid locale or a lack of localized formatting support.

• Locale swap fails because Locale.FRANCE is valid and does not cause the missing zone information.
• ISO formatter fails because it abandons the required localized full-style French output.
• String formatting fails because DateTimeFormatter formats temporal objects, not the text produced by toString().

Question 6

Topic: Implementing Localization

A service must read locale identifiers from configuration as standard BCP 47 language tags. It has these resource bundles: Labels.properties with title=Default and Labels_fr_CA.properties with title=Bonjour.

var configured = "fr_CA";
var locale = Locale.forLanguageTag(configured);
var labels = ResourceBundle.getBundle("Labels", locale);
System.out.println(labels.getString("title"));

The program prints Default, but the team expected Bonjour. What is the best next fix?

Options:

• A. Store fr_CA and call new Locale(configured).

• B. Replace the configured value with Locale.CANADA.toLanguageTag().

• C. Store fr_CA and call new Locale.Builder().setLanguage(configured).build().

• D. Store fr-CA and keep Locale.forLanguageTag(configured).

Best answer: D

Explanation: The configuration value is not a valid BCP 47 language tag because it uses an underscore. Locale.forLanguageTag("fr-CA") creates a locale with language fr and region CA, allowing the Labels_fr_CA.properties bundle to be selected.

Locale language tags use BCP 47 syntax, where subtags are separated with hyphens, such as fr-CA. Resource bundle file names still use underscores, such as Labels_fr_CA.properties, but that is a bundle naming convention, not the input format for Locale.forLanguageTag. Passing fr_CA does not create the intended French Canada locale, so the lookup falls back to the base bundle. Constructors can create locales from separate language and country strings, and Locale.Builder can build from valid components, but neither makes fr_CA a valid language tag for forLanguageTag.

The key distinction is language tag syntax versus resource bundle file naming syntax.

• Single constructor argument treats the whole string as a language value, not as language plus country.
• Builder language component expects only a language subtag such as fr, not fr_CA.
• Canada constant represents English Canada, not French Canada.

Question 7

Topic: Implementing Localization

A reporting job must print the same LocalDate in two localized short date formats. What is the result of running this Java 21 code? Imports are shown.

import java.time.*;
import java.time.format.*;
import java.util.*;

public class ReportDates {
    public static void main(String[] args) {
        var date = LocalDate.of(2025, 3, 4);
        var base = DateTimeFormatter.ofLocalizedDate(FormatStyle.SHORT);
        System.out.println(base.withLocale(Locale.US).format(date));
        System.out.println(base.withLocale(Locale.FRANCE).format(date));
    }
}

Options:

• A. It prints 04/03/2025 and then 3/4/25.

• B. It prints 3/4/25 and then 04/03/2025.

• C. It throws a runtime exception because no time zone is supplied.

• D. It prints 3/4/25 and then 3/4/25.

Best answer: B

Explanation: DateTimeFormatter.ofLocalizedDate(FormatStyle.SHORT) creates a localized date formatter, and withLocale() selects the locale used for formatting. For the given date, Locale.US uses month/day/year, while Locale.FRANCE uses day/month/year.

Localized DateTimeFormatter instances choose their output pattern from the formatter’s locale. The formatter created by ofLocalizedDate(FormatStyle.SHORT) formats only date fields, which a LocalDate provides, so no time zone is required. Calling withLocale(Locale.US) and withLocale(Locale.FRANCE) returns formatter instances that apply different localized short date patterns to the same date. The key takeaway is that localized styles are not fixed string patterns; their actual output depends on the locale attached to the formatter.

• Reversed order fails because the first formatter is explicitly configured with Locale.US, not France.
• Locale ignored fails because withLocale() changes the locale used by the localized formatter.
• Time zone required fails because formatting a LocalDate with a localized date-only formatter does not need zone or time fields.

Question 8

Topic: Implementing Localization

In Java 21, which statement correctly describes ResourceBundle.getBundle(baseName, locale) and bundle.getString(key) when localized data is not available?

Options:

• A. A missing key throws NoSuchElementException; a missing bundle returns null.

• B. A missing bundle or missing key throws MissingResourceException.

• C. A missing bundle creates an empty bundle; a missing key returns the key name.

• D. A missing key returns null; a missing bundle throws MissingResourceException.

Best answer: B

Explanation: ResourceBundle uses MissingResourceException for both missing resources and missing entries. The exception may be thrown when no suitable bundle can be located or when a located bundle does not contain the requested key.

For standard ResourceBundle lookup, ResourceBundle.getBundle(baseName, locale) searches using the bundle lookup rules, including locale fallback. If no suitable bundle can be found, it throws MissingResourceException; it does not return null or create an empty bundle. After a bundle is found, bundle.getString(key) retrieves the localized value for that key. If the key is not present in the resolved bundle or its parent chain, getString also throws MissingResourceException.

The key takeaway is that missing bundle lookup and missing key lookup fail with the same exception type, but at different API calls.

• Null return is wrong because getString does not use null to signal a missing key.
• Empty bundle is wrong because getBundle does not fabricate an empty bundle when lookup fails.
• Wrong exception type is wrong because missing keys use MissingResourceException, not NoSuchElementException.

Question 9

Topic: Implementing Localization

A reporting service compares how the same numeric text is parsed for two locales. What is the output?

import java.text.*;
import java.util.*;

class Report {
  public static void main(String[] args) throws Exception {
    String s = "1.234,56";
    NumberFormat us = NumberFormat.getNumberInstance(Locale.US);
    NumberFormat de = NumberFormat.getNumberInstance(Locale.GERMANY);
    System.out.print(us.parse(s) + " | " + de.parse(s));
  }
}

Options:

• A. 1234.56 | 1234.56

• B. 1.234 | 1234.56

• C. ParseException is thrown before any output

• D. 1234.56 | 1.234

Best answer: B

Explanation: NumberFormat applies the separators of the locale used to create it. The US formatter parses 1.234 as a valid prefix, while the German formatter interprets the entire text as one thousand two hundred thirty-four point fifty-six.

NumberFormat.getNumberInstance(Locale) creates a formatter whose decimal and grouping separators come from that locale. For Locale.US, . is the decimal separator, so parsing starts with 1.234; the following comma is not part of the fraction and parsing stops after the valid prefix. The parse(String) overload does not require the entire input to be consumed; it throws ParseException only when parsing cannot begin. For Locale.GERMANY, . is the grouping separator and , is the decimal separator, so the whole text is interpreted as 1234.56. To require full-input validation, parse with a ParsePosition and check that its index reaches the string length.

• Same numeric value fails because the two locale formatters do not interpret . and , the same way.
• Swapped locale result fails because Germany uses period grouping and comma decimals for this text.
• ParseException assumption fails because parsing successfully begins, even though the US parse stops before the end.

Question 10

Topic: Implementing Localization

Which statement is a correct Java 21 rule for formatting a LocalDate with DateTimeFormatter.ofLocalizedDate(FormatStyle.LONG).withLocale(someLocale)?

Options:

• A. The style selects the locale’s default time zone.

• B. The style defines one exact pattern for all locales.

• C. The locale is ignored after the formatter is created.

• D. The locale selects the localized date pattern and text.

Best answer: D

Explanation: Localized DateTimeFormatter styles combine a FormatStyle with a Locale. For a LocalDate, the locale affects presentation details such as field order, separators, and month text, but it does not change the date value or select a time zone.

In java.time, a localized formatter is not a single fixed pattern. DateTimeFormatter.ofLocalizedDate(FormatStyle.LONG) creates a date formatter whose actual pattern is chosen using the formatter’s locale. Calling withLocale(someLocale) returns a formatter copy that uses that locale for localized formatting and parsing. With a LocalDate, the formatter needs date fields only; there is no instant conversion or time-zone selection involved. If no locale is explicitly set, the default FORMAT locale is used, but withLocale supplies the locale for that formatter.

• Time-zone selection fails because a localized date style does not convert a LocalDate using a locale’s time zone.
• Ignored locale fails because withLocale returns a formatter configured to use the supplied locale.
• One global pattern fails because localized styles resolve to locale-specific patterns, not one universal pattern.

Continue in the web app

Use IT Mastery for interactive Java 21 1Z0-830 practice with mixed sets, timed mocks, topic drills, explanations, and progress tracking.

Try Java 21 1Z0-830 on Web

Related focused pages

• Free Java 21 1Z0-830 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 Deploying Java Code
• Managing Concurrent Code Execution
• Using Java I/O API
• Logging and Annotations