Overview
Domain 3 holds seven of Oracle's objectives, more than any other section. It starts with declaring and instantiating objects, including nested classes, and how references and garbage collection relate to an object's lifecycle. It continues with classes and records, static and instance members, initializer order, overloading with varargs, scope, encapsulation, immutability and var. The heavier half covers inheritance with abstract classes, sealed hierarchies and records, overriding including Object methods, polymorphism, casting, and pattern matching with instanceof and switch.
The final objectives cover interfaces, with default, static and private methods, functional interfaces, and enums that carry fields, constructors and methods. Questions mix compile-error spotting with output prediction, and many test what the compiler allows rather than what a program does.
How it's tested
Questions here are a mix of tracing and rule-checking. Some show a class hierarchy and ask what prints when an overridden method runs through a parent reference. Others show a record, sealed interface or enum declaration and ask which line fails to compile. Read access modifiers and static keywords carefully, because one word often decides the answer.
-
Which method runs
A subclass object sits behind a superclass reference, and you decide whether fields, static methods or instance methods resolve by reference type or object type.
-
Is this declaration legal
A record, sealed type, interface or enum declaration contains one questionable line, such as an instance field in a record or a missing permits clause.
-
Pattern matching output
A switch or instanceof uses type or record patterns, guards and null handling, and you pick the branch taken or the dominance error.
A sealed interface Shape permits only Circle and Square, both records. A switch expression over a Shape has case Circle c and case Square s and no default. It compiles, because the compiler knows the permitted subtypes and sees that both are covered. If a third class were added to the permits list without a matching case, the same switch would fail to compile as non-exhaustive.
Objectives 7
Official objectives from the Oracle outline, in outline order.
3.1 Declare and instantiate Java objects including nested class objects, and explain the object life-cycle including creation, reassigning references, and garbage collection.Constructors, nested and inner class instantiation, references and eligibility for garbage collection.
- What it means
- Objects are created with new, which runs a constructor and returns a reference. Nested types include static nested classes, inner member classes, local classes and anonymous classes. An object becomes eligible for garbage collection once no live thread can reach it through any reference chain.
- What to understand
- An inner member class needs an enclosing instance, so outside the outer class you write outer.new Inner(), while a static nested class is created with new Outer.Nested(). Local and anonymous classes can read local variables only if they are effectively final. For lifecycle questions, track every reference: reassigning a variable or setting it to null can leave an object unreachable, but objects referenced from an array, a field or another reachable object stay alive. Calling System.gc() only suggests collection, and finalize is deprecated, so the exam asks about eligibility, never about when collection actually happens.
- How it shows up
- Expect a sequence of reference assignments followed by a question about how many objects are eligible for collection at a marked line.
- Common confusion
- Believing System.gc() forces collection or that an object is collected the instant its last reference disappears.
3.2 Create classes and records, and define and use instance and static fields and methods, constructors, and instance and static initializers.Class members, constructor chaining, initialization order and record declarations.
- What it means
- A class can declare static and instance fields, methods, constructors and initializer blocks. A record is a concise, final carrier class whose components become private final fields with accessor methods, a canonical constructor, and generated equals, hashCode and toString.
- What to understand
- Initialization order matters: static initializers and static field assignments run once, in source order, when the class is first loaded; then for each new object, the superclass constructor runs, followed by instance initializers and field assignments in source order, then the rest of the constructor body. A constructor's first statement is either this(...) or super(...), and the compiler inserts super() when neither is written. If no constructor is declared, a default no-argument constructor is generated. Records cannot declare instance fields beyond their components, cannot extend a class, and are implicitly final, but they can add static fields, methods, nested types and a compact constructor that validates parameters before fields are assigned. Accessors are named after components, such as name(), not getName().
- How it shows up
- Expect initialization-order output puzzles and record declarations with an illegal instance field or a misnamed accessor.
- Common confusion
- Thinking record accessors follow the getX naming convention or that a compact constructor assigns fields with this.x = x.
3.3 Implement overloaded methods, including var-arg methods.Overload declaration rules and how the compiler selects an overload.
- What it means
- Overloaded methods share a name in one class but differ in parameter lists. Return type and exception lists alone cannot distinguish overloads. A varargs parameter, written Type... name, must be last and accepts zero or more arguments or an array.
- What to understand
- The compiler picks an overload in phases: first an exact or widening primitive match, then boxing or unboxing, and only then varargs. So for a call with an int argument, a long parameter beats an Integer parameter, which beats an int... parameter. If two candidates are equally specific, the call is ambiguous and fails to compile. Passing null to overloads taking String and Object chooses String, because it is more specific. Inside a varargs method the parameter is an ordinary array, and calling it with no arguments passes an empty array, not null.
- How it shows up
- Expect a set of overloads and a call, and you choose which version prints or whether the call is ambiguous.
- Common confusion
- Assuming boxing is preferred over widening, or that changing only the return type creates a valid overload.
3.4 Understand variable scopes, apply encapsulation, and create immutable objects. Use local variable type inference.Scope rules, access control, immutable class design and var.
- What it means
- Variables live in class, instance, method, block or loop scope, and a local variable is visible only from its declaration to the end of its block. Encapsulation hides fields behind private access and exposes behaviour through methods. Immutable objects cannot change state after construction. The var keyword infers a local variable's type from its initializer.
- What to understand
- Know the four access levels and that package-private applies when no modifier is written. Shadowing a field with a local variable is allowed, but redeclaring a local variable in an overlapping scope is not. An immutable class is usually final, has private final fields, no setters, and makes defensive copies of mutable inputs and outputs such as lists or arrays. var works only for local variables with an initializer, including loop variables and try-with-resources resources; it cannot be used for fields, method parameters or return types, cannot be initialized with null alone, and cannot declare several variables in one statement. var is a reserved type name, not a keyword, so it can still be used as a variable name.
- How it shows up
- Expect lines using var in illegal places and immutable class designs that leak a mutable field.
- Common confusion
- Thinking final on a list field makes the list contents immutable, or that var makes Java dynamically typed.
3.5 Implement inheritance, including abstract and sealed types as well as record classes. Override methods, including that of the Object class. Implement polymorphism and differentiate between object type and reference type. Perform reference type casting, identify object types using the instanceof operator, and pattern matching with the instanceof operator and the switch construct.Inheritance, sealed hierarchies, overriding, polymorphism, casting and pattern matching.
- What it means
- A class extends one superclass and inherits its accessible members. Abstract classes cannot be instantiated and can declare abstract methods. Sealed classes and interfaces list their permitted subtypes, and each subtype must be final, sealed or non-sealed. Polymorphism means an overridden instance method runs according to the object's runtime type, whatever the reference type.
- What to understand
- Overriding requires the same signature, a covariant return type, access that is the same or wider, and no broader checked exceptions. Static methods and fields are hidden, not overridden, so they resolve by reference type. Override equals, hashCode and toString with matching signatures, such as equals(Object). A downcast compiles only when the types are related, and fails at runtime with ClassCastException if the object is the wrong type. Pattern matching with instanceof binds a variable, as in obj instanceof String s, and the binding is in scope only where the match is certain. Switch patterns include type patterns, record patterns that deconstruct components, guards written with when, and case null. A more general pattern placed before a more specific one is a dominance compile error, and a sealed hierarchy lets a pattern switch be exhaustive without default.
- How it shows up
- Expect hierarchies printing through a parent reference, record deconstruction patterns, and switches rejected for dominance or missing cases.
- Common confusion
- Thinking fields behave polymorphically like methods, or that a pattern switch over a sealed type always needs default.
3.6 Create and use interfaces, identify functional interfaces, and utilize private, static, and default interface methods.Interface members, default method conflicts and functional interface identification.
- What it means
- Interfaces declare abstract methods and constants, and can also contain default methods with a body, static methods, and private methods that share code between other interface methods. A functional interface has exactly one abstract method, which a lambda or method reference can implement.
- What to understand
- Interface fields are implicitly public static final. Abstract methods are implicitly public. Static interface methods are called through the interface name only and are not inherited by implementing classes. If a class inherits two default methods with the same signature from different interfaces, it must override the method, and it can call a specific version with InterfaceName.super.method(). A class method wins over an interface default. When counting abstract methods for a functional interface, ignore default, static and private methods, and ignore abstract methods that match public methods of Object, such as equals. The @FunctionalInterface annotation is optional but makes the compiler check the rule.
- How it shows up
- Expect code that calls a static interface method through an instance, and default-method conflicts between two interfaces.
- Common confusion
- Counting equals(Object) or default methods as abstract methods when deciding whether an interface is functional.
3.7 Create and use enum types with fields, methods, and constructors.Enum declarations, constructors, constant-specific bodies and built-in enum methods.
- What it means
- An enum defines a fixed set of named constants, each an instance of the enum type. Enums can declare fields, constructors, methods, and constant-specific class bodies that override methods for one constant. They can implement interfaces but cannot extend another class.
- What to understand
- Enum constructors are implicitly private and run once for each constant when the enum is initialized. The constants must be listed first, followed by a semicolon if other members follow. values() returns an array in declaration order, valueOf(String) returns the matching constant or throws IllegalArgumentException, ordinal() gives the zero-based position, and name() returns the declared name. Enums compare safely with ==, and in a switch the case labels use the bare constant name. An abstract method declared in the enum must be implemented by every constant's body.
- How it shows up
- Expect enums with constructors that print, valueOf with a wrong-case String, and constant-specific method overrides.
- Common confusion
- Calling an enum constructor with new or expecting valueOf to ignore letter case.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Initialization order
Static parts once per class, then superclass constructor, then instance initializers.
- Remember
- Initializers and field assignments run in source order.
- Tested as
- Output puzzles with print statements in blocks.
- Trap
- Running instance initializers before the superclass constructor.
-
Record
Final, immutable-style data carrier with generated members.
- Remember
- No extra instance fields; accessors use component names.
- Tested as
- Declaration legality questions.
- Trap
- Calling getX() on a record.
-
Compact constructor
Record constructor without a parameter list.
- Remember
- Fields are assigned automatically after it runs.
- Tested as
- Validation scenarios.
- Trap
- Assigning this.x inside it.
-
Overload resolution
Widening, then boxing, then varargs.
- Remember
- Ambiguous calls fail to compile.
- Tested as
- Which-method-prints questions.
- Trap
- Choosing boxing over widening.
-
var
Local variable type inference from the initializer.
- Remember
- Not for fields, parameters or null-only initializers.
- Tested as
- Compile-error spotting.
- Trap
- Thinking var changes static typing.
-
Sealed type
Class or interface that restricts its direct subtypes.
- Remember
- Subtypes must be final, sealed or non-sealed.
- Tested as
- Hierarchy legality and exhaustiveness.
- Trap
- Leaving a permitted subclass without a modifier.
-
Field hiding
Fields resolve by reference type, not object type.
- Remember
- Only instance methods are polymorphic.
- Tested as
- Output through a parent reference.
- Trap
- Expecting the subclass field value.
-
Pattern dominance
A broader pattern before a narrower one blocks it.
- Remember
- The compiler rejects dominated case labels.
- Tested as
- Switch compile errors.
- Trap
- Assuming later cases are simply unreachable at runtime.
-
Record pattern
Deconstructs a record's components in a pattern.
- Remember
- Works in instanceof and switch, with nesting.
- Tested as
- Java 21 pattern questions.
- Trap
- Mismatching component order or count.
-
Default method conflict
Two inherited defaults with the same signature.
- Remember
- The class must override and may call X.super.m().
- Tested as
- Interface compile errors.
- Trap
- Thinking the first interface listed wins.
-
Functional interface
Exactly one abstract method.
- Remember
- Object methods and defaults do not count.
- Tested as
- Lambda target questions.
- Trap
- Rejecting Comparator because it declares equals.
-
Enum constructor
Implicitly private, runs once per constant.
- Remember
- Constants come first in the body.
- Tested as
- Output of enum initialization.
- Trap
- Trying to instantiate an enum with new.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Type declarations
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Abstract class | Partial implementation that cannot be instantiated | Can hold state and constructors | Instantiating it directly |
| Interface | Contract with optional default, static and private methods | No instance state; multiple inheritance of type | Calling static methods through an instance |
| Record | Final data carrier with generated members | Cannot extend classes or add instance fields | Expecting setters or getX accessors |
| Enum | Fixed set of constant instances | Private constructors; can implement interfaces | Extending another class |
Resolution by reference type or object type
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Instance method | Overridable behaviour | Resolved by object type at runtime | Predicting the parent version |
| Static method | Class-level behaviour | Hidden, resolved by reference type | Treating it as overridden |
| Field | State stored in each class | Hidden, resolved by reference type | Expecting the subclass value through a parent reference |
Sealed subtype modifiers
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| final | No further subclasses | Closes the branch | Forgetting a permitted class needs a modifier |
| sealed | Further restricted subtypes | Needs its own permits list or same-file subclasses | Omitting permitted subtypes |
| non-sealed | Reopens the branch to any subclass | Breaks exhaustiveness below that point | Assuming the whole hierarchy stays closed |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Polymorphic fields
- What candidates pick
- Picks the subclass field value through a parent reference.
- Why it looks right
- Methods behave polymorphically, so fields seem to as well.
- Why it's wrong
- Fields are hidden rather than overridden and resolve by the reference's declared type.
Clue to watch for Same-named fields in parent and child classes.
-
Boxing before widening
- What candidates pick
- Chooses the Integer overload for an int argument when a long overload exists.
- Why it looks right
- Integer feels closer to int than long does.
- Why it's wrong
- The compiler tries widening before boxing, so the long overload is selected.
Clue to watch for Overloads taking long, Integer and int...
-
Static methods override
- What candidates pick
- Expects the subclass static method to run through a parent reference.
- Why it looks right
- The method signature matches exactly.
- Why it's wrong
- Static methods are hidden, so the reference type decides which version runs.
Clue to watch for The static keyword on both methods.
-
Sealed switch needs default
- What candidates pick
- Adds or expects a default branch to make a switch over a sealed interface compile.
- Why it looks right
- Default is usually required for exhaustiveness.
- Why it's wrong
- When every permitted subtype is covered, the compiler already treats the switch as exhaustive.
Clue to watch for A sealed interface with a permits list and one case per subtype.
-
Record with extra field
- What candidates pick
- Accepts a record declaring a private instance field.
- Why it looks right
- Ordinary classes allow this freely.
- Why it's wrong
- Records may add static fields only; extra instance state must come from components.
Clue to watch for A non-static field declared inside a record body.
-
Interface static via instance
- What candidates pick
- Selects code calling a static interface method through an implementing object.
- Why it looks right
- Class static methods can be called through instances.
- Why it's wrong
- Static interface methods are not inherited and must be called with the interface name.
Clue to watch for An implementing class instance used to call a static interface method.
Answer framework
Use this sequence for object-oriented questions, checking compile rules before tracing behaviour.
- Check every declaration for legality: modifiers on sealed subtypes, record restrictions, interface member rules, enum constant placement and constructor chaining.
- Identify the reference type and the object type for each variable, because fields and static methods follow the reference while instance methods follow the object.
- For overloaded calls, apply the phases in order: exact or widening match, then boxing, then varargs, and flag ambiguity.
- For pattern matching, confirm dominance order, guard conditions, null handling and whether sealed types make the switch exhaustive.
- Trace initialization and output last, listing static blocks, superclass constructors, instance initializers and constructor bodies in the order they actually run.
Practice question
Want more like this? The 1Z0-830 practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Give this section the most time, and split it into three blocks. In the first block, cover objects, classes and records: write a class with static and instance initializers that print, create a subclass, and confirm the order of output. Declare records, add a compact constructor, and try adding an instance field to read the compiler error. Add overloads with long, Integer and int... parameters and call them with different arguments.
In the second block, focus on inheritance and patterns. Build a sealed interface with record implementations and write switch expressions using type patterns, record patterns, guards and case null. Deliberately put a broad case first to see the dominance error, then add a non-sealed subtype and watch exhaustiveness change.
In the third block, cover interfaces and enums: default method conflicts, static and private interface methods, and enums with constructors. After each block, answer practice items and record the rule behind each miss. Revisit the field hiding and overload phase rules several times, since they are easy to forget.
FAQ
How much of 1Z0-830 is Domain 3, Using Object-Oriented Concepts in Java?
Oracle publishes no weights, but this section lists seven objectives, the most of any section. We plan for about ten of the 50 questions and the largest share of study time.
Are record patterns final in Java 21?
Yes. Record patterns and pattern matching for switch both became standard features in Java 21, so they are in scope for this exam.
Are unnamed patterns using the underscore on the exam?
In Java 21 unnamed patterns and variables were a preview feature. Oracle exams target standard features, so concentrate on finalized pattern syntax.
Do I need to know garbage collection algorithms?
No. The objective is about when an object becomes eligible for collection based on reachability, not about how collectors work or tune memory.
Can a record implement an interface?
Yes. Records can implement interfaces, including sealed interfaces, which is a common way to build exhaustive pattern-matching hierarchies.
What happens if a sealed class's subclass has no modifier?
Compilation fails. Every permitted direct subtype of a sealed class must be declared final, sealed or non-sealed, except records and enums, which are implicitly final.
Is finalize part of the lifecycle objective?
finalize is deprecated for removal. Expect questions on creation, reference reassignment and eligibility for collection rather than on finalization.
Test your Domain 3 knowledge
You have reviewed object lifecycle, classes and records, overloading, sealed hierarchies, polymorphism, pattern matching, interfaces and enums. See whether you can spot compile errors and trace output quickly.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the 1Z0-830 AI tutor Get any concept explained your way