Java 17 1Z0-829: Object-Oriented Java

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: Utilizing Java Object-Oriented Approach

An API must expose a ReleasePlan whose list of review dates cannot be changed after construction. LocalDate values are immutable. The constructor must reject a null or blank id, a null or empty list, and any null list element. Which implementation of the TODOs best satisfies these requirements?

final class ReleasePlan {
    private final String id;
    private final List<LocalDate> reviewDates;

    ReleasePlan(String id, List<LocalDate> dates) {
        if (id == null || id.isBlank() || dates == null || dates.isEmpty())
            throw new IllegalArgumentException();
        this.id = id;
        // constructor TODO
    }

    String id() { return id; }
    List<LocalDate> reviewDates() { /* accessor TODO */ }
}

Options:

• A. Set this.reviewDates = List.copyOf(dates); and return reviewDates.

• B. Set this.reviewDates = Collections.unmodifiableList(dates); and return reviewDates.

• C. Set this.reviewDates = new ArrayList<>(dates); and return reviewDates.

• D. Set this.reviewDates = dates; and return List.copyOf(reviewDates).

Best answer: A

Explanation: The safest implementation makes a defensive copy during construction and exposes only an unmodifiable list. Because LocalDate is immutable, copying the list structure is enough; the individual elements do not need defensive copies.

Immutable classes need more than private final fields when a field refers to a mutable object such as a List. The constructor must not keep a caller-owned mutable list, because the caller could change it after the object is built. In Java 17, List.copyOf(dates) creates an unmodifiable copy and throws NullPointerException if any element is null, satisfying the null-element rejection requirement. Since the stored list cannot be structurally modified and LocalDate itself is immutable, the accessor can safely return the stored list reference.

• Accessor-only copy fails because assigning dates directly lets later caller mutations change the object’s state.
• Unmodifiable view fails because Collections.unmodifiableList(dates) still reflects changes made to the backing list.
• Mutable stored copy fails because returning the stored ArrayList allows callers to mutate the internal list.

Question 2

Topic: Utilizing Java Object-Oriented Approach

A Java 17 class declares static field initializers, static initializer blocks, instance field initializers, instance initializer blocks, and a constructor that does not delegate with this(...). Which initialization rule is correct when an object is created and the class has not yet been initialized?

Options:

• A. Static members run in source order once; instance initializers run before the constructor body.

• B. Instance initializer blocks run after the constructor body completes.

• C. All static fields initialize before any static block, regardless of source order.

• D. Static initializer blocks run each time a new object is created.

Best answer: A

Explanation: Java uses source order within each initializer category. Static field initializers and static blocks execute once when the class is initialized, and instance field initializers and instance blocks execute for each object before the constructor body runs.

For a class that is being initialized for the first time, Java first performs class initialization: static field initializers and static initializer blocks execute in the order they appear in the source file. After the object is allocated and fields have default values, instance field initializers and instance initializer blocks also execute in source order before the constructor body of the non-delegating constructor. Static initialization is per class, while instance initialization is per object.

The key distinction is not “fields before blocks”; it is source order within static initialization and source order within instance initialization.

• Fields before blocks is wrong because Java does not group all static fields before all static blocks.
• After constructor body is wrong because instance initializers run before the constructor body.
• Per-object static blocks is wrong because static initializer blocks run during class initialization, not for every object.

Question 3

Topic: Utilizing Java Object-Oriented Approach

A developer is refactoring a method to use a Java 17 switch expression over an enum. Which replacement for /* cases */ compiles?

enum Phase { STARTED, RUNNING, FINISHED }

static String message(Phase p) {
    return switch (p) {
        /* cases */
    };
}

Options:

• A. case Phase.STARTED -> "start"; case Phase.RUNNING -> "run"; case Phase.FINISHED -> "done";

• B. case STARTED -> "start"; case RUNNING -> "run"; case FINISHED -> "done";

• C. case STARTED -> "start"; case RUNNING -> "run";

• D. case "STARTED" -> "start"; case "RUNNING" -> "run"; case "FINISHED" -> "done";

Best answer: B

Explanation: A switch whose selector is an enum uses enum constants as case labels. In Java 17, those enum constants are written as unqualified names inside the switch block, and a switch expression must be exhaustive.

The selector expression p has type Phase, so each case label must be compatible with that enum type. For enum switch labels in Java 17, use the simple constant name such as STARTED, not Phase.STARTED. Because this is a switch expression returning a value, the switch must also cover all possible enum constants or provide a default. Covering STARTED, RUNNING, and FINISHED satisfies that rule.

The key distinction is enum constant labels versus other constant types or incomplete switch expression coverage.

• Qualified enum names fail because Java 17 enum switch labels use simple constant names in this context.
• String labels fail because the selector type is Phase, not String.
• Missing enum constant fails because a switch expression without default must be exhaustive.

Question 4

Topic: Utilizing Java Object-Oriented Approach

A team is converting an immutable value class to this Java 17 record. Assume callers pass a non-null code. The record must reject an empty trimmed code, reject nonpositive percentages, store the trimmed code, and keep the normal record-generated members.

public record Coupon(String code, int percent) {
    public Coupon {
        this.code = code.strip();
        if (this.code.isEmpty() || percent <= 0)
            throw new IllegalArgumentException();
    }
}

Which refactoring is the best fix?

Options:

• A. Replace the constructor with:

public Coupon {
    code = code.strip();
    if (code.isEmpty() || percent <= 0)
        throw new IllegalArgumentException();
}

• B. Replace the constructor with a trimming accessor:

public String code() {
    return code.strip();
}

• C. Use renamed parameters in an explicit canonical constructor:

public Coupon(String value, int pct) {
    value = value.strip();
    if (value.isEmpty() || pct <= 0)
        throw new IllegalArgumentException();
    this.code = value;
    this.percent = pct;
}

• D. Assign the fields directly in the compact constructor:

public Coupon {
    this.code = code.strip();
    this.percent = percent;
}

Best answer: A

Explanation: In a compact record constructor, the component names are parameters, not fields to be assigned directly. Reassigning code normalizes the value that the compiler later stores in the private final component field, while the generated accessor and other members remain available.

A compact canonical constructor is designed for validation and normalization of record components. Its body runs before the compiler-inserted assignments to the component fields. Inside the body, code and percent refer to constructor parameters, so code = code.strip() changes the parameter value that will later be stored. Assigning this.code or this.percent in a compact constructor is not allowed. If an explicit canonical constructor is used instead, its parameter list must match the record components. Keeping the compact form preserves the normal generated code(), percent(), equals(), hashCode(), and toString() behavior.

• Direct field assignment fails because compact constructors cannot assign record component fields such as this.code.
• Renamed canonical parameters fail because an explicit canonical constructor must use the record component names and types.
• Accessor-only trimming leaves the stored component unchanged and does not validate percent during construction.

Question 5

Topic: Utilizing Java Object-Oriented Approach

A team is turning this class into part of a Java 17 library API. Code in other packages must call new InventoryItem(...), read the SKU and quantity, and change the quantity only through a validated method.

package store;

class InventoryItem {
    public String sku;
    int quantity;

    InventoryItem(String sku, int quantity) {
        this.sku = sku;
        this.quantity = quantity;
    }

    void add(int amount) { quantity += amount; }
}

Which refactor is the best fix?

Options:

• A. Declare the top-level type protected and use protected fields and methods.

• B. Keep the type package-private, but make the constructor and methods public.

• C. Make the type public and keep the fields public for direct access.

• D. Make the type public, fields private, constructor/getters/add public, helpers private.

Best answer: D

Explanation: The class itself must be accessible from other packages, so the top-level type must be public. Encapsulation is preserved by making fields private and exposing only the intended public constructor, accessors, and validated mutator method.

Java access control applies separately to the top-level type, its constructors, fields, and methods. A class used from another package must be a public top-level class, and callers using new InventoryItem(...) need an accessible constructor. The mutable state should not be directly exposed, so sku and quantity should be private, with public getters and a public add method that performs validation. Any validation helper that is not part of the API should be private.

Top-level classes can be only public or package-private, not protected or private.

• Public members only fails because a public constructor or method cannot make a package-private top-level type usable from another package.
• Public fields fails because callers could change state without validation, breaking encapsulation.
• Protected type fails because protected is not a legal modifier for a top-level class.

Question 6

Topic: Utilizing Java Object-Oriented Approach

A team wants this Java 17 record to reject null or blank account IDs and store the stripped value. The record currently fails to compile. Which refactor is the best fix while keeping the compact constructor form?

public record AccountId(String value) {
    public AccountId {
        if (value == null || value.isBlank()) {
            throw new IllegalArgumentException("missing id");
        }
        this.value = value.strip();
    }
}

Options:

• A. Add private String value; and assign that field

• B. Add a setter and call it from the constructor

• C. Replace the last line with value = value.strip();

• D. Keep this.value = value.strip(); in the compact constructor

Best answer: C

Explanation: Record component fields are final and are not assigned directly inside a compact constructor. The compact constructor body works with the implicit constructor parameters, and Java assigns the component fields after the body completes.

A compact constructor is a canonical constructor without an explicit parameter list. Inside its body, the component names such as value refer to the implicit constructor parameters, which may be validated or reassigned for normalization. After the compact constructor body finishes, the compiler assigns the record’s final component fields from those parameter values. Therefore, assigning value = value.strip(); stores the normalized value, while this.value = ... is not allowed in the compact constructor body.

The key takeaway is to normalize the parameter, not the record component field.

• Direct field assignment fails because compact constructors cannot assign to the record component fields.
• Extra instance field fails because records cannot add arbitrary instance fields to bypass components.
• Setter-based mutation fails because record components are final and records are not designed for component mutation.

Question 7

Topic: Utilizing Java Object-Oriented Approach

A shipping service models a SKU as a Java SE 17 record. The record must have one component code, reject blank codes, store the stripped version, expose a static prefix constant, and provide an instance method label(). Which declaration compiles and meets these requirements?

Options:

• A. ```java record Sku(String code) { public static final String PREFIX = “SKU-”; public Sku(String code) { code = code.strip(); if (code.isBlank()) throw new IllegalArgumentException(); } String label() { return PREFIX + code; } }

- B. ```java
record Sku(String code) {
    public static final String PREFIX = "SKU-";
    public Sku {
        if (code.isBlank()) throw new IllegalArgumentException();
        this.code = code.strip();
    }
    String label() { return PREFIX + code; }
}

• C. ```java record Sku(String code) { public static final String PREFIX = “SKU-”; private String cachedLabel; public Sku { code = code.strip(); } String label() { return PREFIX + code; } }

- D. ```java
record Sku(String code) {
    public static final String PREFIX = "SKU-";
    public Sku {
        code = code.strip();
        if (code.isBlank()) throw new IllegalArgumentException();
    }
    String label() { return PREFIX + code; }
}

Best answer: D

Explanation: A record may declare static fields and instance methods. Its compact constructor can normalize the component parameter, and the compiler assigns the resulting parameter value to the private final component field after the constructor body.

Java records automatically declare private final fields, public accessors, and a canonical constructor for their components. A record body may contain static fields, constructors, and instance methods, but it cannot add extra non-static instance fields. In a compact constructor, the component parameters are in scope, so code can validate them and reassign the parameter variable, such as code = code.strip(). After the compact constructor body completes, Java assigns the current parameter values to the record fields. Direct assignment to this.code is not allowed in a compact constructor, and an explicit canonical constructor must assign the component field itself.

• Extra instance field fails because records cannot declare additional non-static instance fields.
• Explicit constructor fails because changing the local parameter does not initialize the record component field.
• Direct field assignment fails because compact constructors rely on implicit assignment after the body.

Question 8

Topic: Utilizing Java Object-Oriented Approach

Which Java 17 access-control rule is correct when designing an encapsulated class?

Options:

• A. A protected constructor is callable from every package.

• B. A top-level class can be public or package-private only.

• C. A public method hides a private field from reflection.

• D. A private field is inherited and directly accessible by subclasses.

Best answer: B

Explanation: Java limits access modifiers differently depending on what is being declared. For top-level types, Java 17 allows only public or no access modifier, which means package-private access.

Access control supports encapsulation by limiting who can directly use a type or member. In Java 17, a top-level class or interface may be declared public, or it may omit an access modifier for package-private access. It cannot be declared private or protected. Members such as fields, constructors, methods, and nested types have different access possibilities, so the rule for top-level types is narrower than the rule for members.

A common encapsulation pattern is to make fields private and expose controlled behavior through methods or constructors with suitable access levels.

• Private inheritance fails because private fields are not directly accessible by subclasses.
• Protected access fails because protected is not the same as public access from every package.
• Reflection claim fails because access modifiers do not mean a public method prevents reflective inspection.

Question 9

Topic: Utilizing Java Object-Oriented Approach

A developer is troubleshooting this Java 17 code. It compiles, but running Child prints null child, while the developer expected parent child.

class Parent {
    String name = "parent";
    Parent() { show(); }
    void show() { System.out.print(name + " "); }
}
class Child extends Parent {
    String name = "child";
    @Override void show() { System.out.print(name + " "); }
    Child() { System.out.print(name); }
    public static void main(String[] args) { new Child(); }
}

Which option identifies the best cause of the symptom?

Options:

• A. The @Override annotation delays field initialization until Child() finishes.

• B. The parent constructor dispatches to Child.show() before Child.name is initialized.

• C. Child.name replaces Parent.name before the parent field initializer runs.

• D. Fields are resolved dynamically, so Parent.show() reads Child.name.

Best answer: B

Explanation: Constructors run from superclass to subclass, but overridden method calls still use dynamic dispatch. When Parent() calls show(), Java invokes Child.show(), and Child.name has not yet been initialized, so it prints null.

The core issue is calling an overridable instance method during object construction. Before Child() runs, Java first initializes Parent fields and executes Parent(). The call to show() inside Parent() is dynamically dispatched to Child.show(), not Parent.show(). However, Child instance field initializers have not run yet, so the shadowing field Child.name still contains its default value, null. After Parent() returns, Child.name is initialized to "child", and the Child() constructor prints it.

The key takeaway is to avoid calling overridable methods from constructors when subclass state may not be initialized.

• Field replacement is wrong because Child.name shadows Parent.name; it does not replace it or run before parent initialization.
• Annotation behavior is wrong because @Override only checks overriding at compile time and does not affect initialization order.
• Dynamic field lookup is wrong because fields are resolved by declared context, while instance methods are dynamically dispatched.

Question 10

Topic: Utilizing Java Object-Oriented Approach

A team is refactoring routing logic to a Java 17 switch expression. It must keep the selector type as the enum and compile without enabling preview features.

enum Level { DEBUG, INFO, ERROR }

class Router {
    static String route(Level level) {
        return switch (level) {
            case Level.DEBUG -> "dev";
            case Level.INFO -> "ops";
            case Level.ERROR -> "page";
        };
    }
}

Which refactor is the best correction?

Options:

• A. Use guarded pattern labels such as case Level l when l == Level.DEBUG.

• B. Add default -> "unknown" and leave the labels qualified.

• C. Switch on level.name() and use string labels "DEBUG", "INFO", and "ERROR".

• D. Replace the labels with case DEBUG, case INFO, and case ERROR.

Best answer: D

Explanation: Java 17 supports switching directly on an enum value. For an enum selector, the case labels are the simple enum constant names, so qualifying them with Level. is the defect. The existing switch expression already covers all constants.

The selector expression level has type Level, so each case label must name a constant of that enum using its simple name: DEBUG, INFO, and ERROR. In an enum switch, case Level.DEBUG is not the valid label form. Because the switch expression lists every Level constant, it is exhaustive and does not need a default branch. Switching on level.name() would change the selector to String and lose the enum type-safety required by the scenario.

• String selector compiles with string labels but violates the requirement to keep the enum as the selector type.
• Default branch addresses exhaustiveness, not the invalid qualified enum labels.
• Guarded patterns rely on switch pattern features that are not standard Java SE 17 syntax for this exam scope.

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
• 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
• Implementing Localization
• 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.