3.1 Class Declarations, Field/Method Signatures, and Access Modifiers

Oracle Java SE 17 Developer Certified Professional 1Z0-829

Track your progress as you read

Finished sections get a check mark.

1 Introduction: The 1Z0-829 Exam

About the Java SE 17 Developer (1Z0-829) Exam

2 Chapter 1: Java Fundamentals & Language Basics

1.1 Primitive Types, Literals, Wrapper Classes, and Type Promotion/Casting 1.2 Local Variable Type Inference (`var`) Rules and Scoping 1.3 Operators, Precedence, Evaluation Order, and Short-Circuit Evaluation 1.4 Text Blocks, String Immutability, and StringBuilder APIs

3 Chapter 2: Program Flow & Decision Constructs

2.1 Conditional Branching with if/else and the Ternary Operator 2.2 Switch Statements and Switch Expressions 2.3 Iteration Constructs, Loop Control, and Branching Labels

4 Chapter 3: Object-Oriented Design & Class Mechanics

3.1 Class Declarations, Field/Method Signatures, and Access Modifiers 3.2 Constructors, Overloading, Initialization Order, and Garbage Collection 3.3 Inheritance, Method Overriding, Polymorphism, and `super`/`this` 3.4 Abstract Classes, Static Members, and Object Methods (`equals`, `hashCode`, `toString`)

5 Chapter 4: Advanced OOP: Interfaces, Records & Sealed Types

4.1 Interface Architecture: Default, Static, and Private Methods 4.2 Enumerations: Constants, Constructors, Methods, and Custom Bodies 4.3 Records: Canonical/Compact Constructors, Components, and Immutability 4.4 Sealed Classes and Interfaces: `permits`, Hierarchy Constraints, and Modifiers

6 Chapter 5: Pattern Matching & Nested Types

5.1 Pattern Matching for `instanceof` and Flow Scoping Mechanics 5.2 Nested Types: Member Inner, Static Nested, Local, and Anonymous Classes 5.3 Defensive Programming, Immutability Patterns, and Validation

7 Chapter 6: Generics, Collections & Arrays

6.1 Generic Classes, Interfaces, Methods, and Type Erasure 6.2 Bounded Type Parameters and Wildcards (PECS Rule) 6.3 Collections Framework: List, Set, Queue, and Deque APIs 6.4 The Map Interface, Sorting, Comparable, and Comparator 6.5 Arrays: Declaration, Initialization, Multidimensional Arrays, and the Arrays Utility Class

8 Chapter 7: Functional Programming & Lambda Expressions

7.1 Functional Interfaces and Lambda Syntax Rules 7.2 Standard Functional Interfaces in `java.util.function` 7.3 Method References: Static, Bound, Unbound, and Constructor References

9 Chapter 8: The Stream API

8.1 Stream Lifecycle: Creation, Pipeline Architecture, and Lazy Evaluation 8.2 Intermediate Stream Operations: Filtering, Mapping, Sorting, and Slicing 8.3 Terminal Stream Operations: Reduction, Matching, Finding, and Collecting 8.4 Primitive Streams (`IntStream`, `LongStream`, `DoubleStream`) and Numeric Statistics

10 Chapter 9: Advanced Streams & Collectors

9.1 The Optional Class: Safe Null Handling, Transformation, and Chaining 9.2 The Collectors API: Downstream Reductions, Grouping, and Partitioning 9.3 Parallel Streams: Fork/Join Pool, Spliterators, and Concurrency Pitfalls

11 Chapter 10: Exception Handling

10.1 The Java Exception Hierarchy: Checked vs. Unchecked Exceptions and Errors 10.2 Exception Constructs: `try-catch-finally`, Multi-Catch, and Rethrowing 10.3 Try-With-Resources, `AutoCloseable`, Suppressed Exceptions, and Custom Exceptions

12 Chapter 11: Date/Time API & Localization

11.1 Date and Time Core Types: `LocalDate`, `LocalTime`, `LocalDateTime` 11.2 Timestamps, Intervals, and Durations: `Instant`, `Period`, and `Duration` 11.3 Time Zones, Daylight Saving Time (DST) Offsets, and `ZonedDateTime` 11.4 Internationalization and Localization: `Locale`, `ResourceBundle`, and Formatters 11.5 Formatting and Parsing Messages, Numbers, Percentages, and Localized Dates

13 Chapter 12: Java Platform Module System (JPMS)

12.1 Module Architecture, `module-info.java`, and Module Paths 12.2 Module Directives: `requires`, `requires transitive`, `exports`, and Qualified Exports 12.3 Reflection, Deep Encapsulation, `opens`, and Open Modules 12.4 Services in JPMS (`uses`, `provides...with`), Migration Paths, and Tooling (`jlink`, `jdeps`) 12.5 Compiling and Packaging Code: Non-Modular JARs, Modular JARs, and Migration Strategies

14 Chapter 13: Concurrency & Multithreading

13.1 Thread Fundamentals, `Runnable`, `Callable`, and Thread Lifecycle 13.2 Memory Visibility, `volatile`, Intrinsic Locks, and Synchronization 13.3 The Concurrency Framework: `ExecutorService`, Thread Pools, and `Future` 13.4 Concurrent Collections, Atomic Variables, Explicit Locks, and `CompletableFuture`

15 Chapter 14: Java I/O and NIO.2

14.1 Classical I/O: Byte and Character Streams, Readers, Writers, and Buffering 14.2 Object Serialization, `Serializable`, `transient`, and `serialVersionUID` 14.3 NIO.2 Architecture: `Path`, `Paths`, and Basic `Files` Operations 14.4 Advanced NIO.2: Directory Walking, Streams (`Files.lines`, `walk`), and `WatchService`

16 Chapter 15: Accessing Databases with JDBC

15.1 JDBC Architecture, Drivers, `DriverManager`, and `DataSource` Connections 15.2 SQL Execution: `Statement`, `PreparedStatement`, and `CallableStatement` 15.3 `ResultSet` Navigation, Data Types, and Transaction Management (Commit, Rollback, Savepoints)

17 Chapter 16: Annotations & the Java Logging API

16.1 Standard Annotations: @Override, @FunctionalInterface, @Deprecated, @SuppressWarnings, and @SafeVarargs 16.2 Java Logging API Basics: Logger, Levels, Handlers, and Configuration

3.1 Class Declarations, Field/Method Signatures, and Access Modifiers

Key Takeaways Explain This Topic AI

A Java source file (.java) can have at most one public top-level class, which must match the filename case-sensitively, though it may contain multiple package-private classes.

Member access modifiers form a strict hierarchy (public > protected > package-private > private); protected members are accessible across package boundaries only through inheritance within the subclass context.

Method signatures consist solely of the method name and parameter types in order; return types, access modifiers, and throws clauses do not differentiate overloaded methods.

Overload resolution follows a strict four-tier precedence: exact matches, followed by primitive widening, autoboxing/unboxing, and finally varargs.

Varargs parameters must appear as the final parameter in a formal parameter list and at most one varargs parameter is permitted per method declaration.

Last updated: October 2026

Class Declarations, Field/Method Signatures, and Access Modifiers

Object-oriented programming in Java begins with the precise structural declaration of classes, their packages, and their accessible members. The Oracle Java SE 17 Developer certification exam tests subtle rules regarding top-level declarations, import resolution, cross-package accessibility, and method dispatch resolution.

1. Class Declarations and Class Modifiers

A top-level class declaration introduces a reference type to the Java compiler. At the class level, access and behavior are governed by a specific subset of access modifiers and non-access specifiers.

Top-Level Access Modifiers

A top-level class can only use two access levels:

public : Accessible by any other class in any package across modular boundaries (assuming the package is exported if inside a Java module).

Package-Private (Default) : Declared without an explicit access modifier. Accessible only by classes residing in the identical package.

Warning

Declaring a top-level class as private or protected results in a compilation error: modifier private/protected not allowed here . These modifiers are only permitted on nested or inner classes.

Source File Structure Rules

A single .java compilation unit can declare at most one public top-level class.

If a public class is present, the filename must match the name of the public class exactly, including case (e.g., public class UserAccount must reside in UserAccount.java ).

A source file may contain multiple top-level classes provided that none or only one of them is public . The non-public classes have package-private accessibility.

Non-Access Class Specifiers

final : Prevents the class from being extended by any subclass. Common examples in the Java standard library include java.lang.String , java.lang.Integer , and java.lang.Math .

abstract : Denotes an incomplete class that cannot be directly instantiated via new . An abstract class serves as a supertype for concrete subclasses.

strictfp : In Java 17, strictfp is effectively obsolete. Under JEP 306, Java SE 17 restored consistently strict floating-point semantics (strict conformance to IEEE 754) for all floating-point expressions across all platforms. While the strictfp keyword remains valid syntax for backward compatibility, specifying it has no operational effect.

Warning

The combination final abstract (or abstract final ) is an illegal modifier collision and causes a compile-time error: illegal combination of modifiers: abstract and final . An abstract class demands extension, whereas a final class prohibits it.

• 2. Package Structure and Import Mechanics
• Package Declarations

A package declaration groups related classes into a shared namespace. If present, the package statement must be the first non-comment, non-whitespace token in the .java file. If omitted, the compilation unit belongs to the unnamed default package. package com.exam.model; // Must be line 1 (ignoring comments)

import java.util.List;

• public class Inventory {}
• Import Types and Shadowing

Java provides three distinct import styles:

Single-Type Import : import java.util.List; imports a specific type.

Type-Import-on-Demand (Wildcard) : import java.util.*; imports all public classes and interfaces within java.util . Wildcards do not import subpackages. For example, import java.util.*; does not import java.util.concurrent.ConcurrentHashMap .

Static Import : Imports static members (fields or methods) directly into scope without qualifying them with the class name. import static java.lang.Math.PI;

• import static java.lang.Math.sqrt;
• import static java.util.Collections.*;

Warning

Static imports must import static members , not classes. Writing import static java.lang.Math; fails compilation with canonical name expected . To import the Math class itself, write import java.lang.Math; .

Naming Collisions and Precedence

When two packages contain a class with the same simple name, precedence determines how the name resolves:

Single-type imports take precedence over wildcard imports. If import java.util.Date; and import java.sql.*; are both declared, Date unambiguously resolves to java.util.Date .

Types in the same package take precedence over wildcard imports. A class named Date in the current package shadows import java.util.*; .

Two conflicting wildcard imports cause ambiguity. If import java.util.*; and import java.sql.*; are present, referencing Date directly causes a compile-time error: reference to Date is ambiguous . The developer must use the fully qualified class name (FQCN), such as java.sql.Date d = new java.sql.Date(...); .

3. Member Access Modifiers

Class members (fields, methods, constructors, and nested types) can declare one of four access modifiers.

• Modifier Same Class Same Package Subclass (Different Package) Non-Subclass (Different Package)
• public Yes Yes Yes Yes
• protected Yes Yes Yes (via inheritance only) No
• Package-Private (default) Yes Yes No No
• private Yes No No No
• The protected Cross-Package Nuance

The protected access modifier permits access to any class in the same package, but across package boundaries, access is granted only to subclasses through inheritance .

A subclass in another package can access a protected member on an instance of itself (or its subclasses) or through super . It cannot access that protected member through a reference to the superclass. // File: pkgA/SuperClass.java

• package pkgA;
• public class SuperClass {
• protected int rating = 10;
• }

• // File: pkgB/SubClass.java
• package pkgB;
• import pkgA.SuperClass;

• public class SubClass extends SuperClass {
• public void inspect() {
• System.out.println(this.rating); // COMPILES: accessed via inheritance
• System.out.println(super.rating); // COMPILES: accessed via super

• SubClass sub = new SubClass();
• System.out.println(sub.rating); // COMPILES: accessed through SubClass reference

• SuperClass sup = new SuperClass();
• // System.out.println(sup.rating); // COMPILE ERROR: rating has protected access in SuperClass
• }
• }
• 4. Method Signatures and Declarations

A method signature is strictly composed of two elements: Method Signature = Method Name + Formal Parameter Types (in order) \text{Method Signature} = \text{Method Name} + \text{Formal Parameter Types (in order)} Method Signature = Method Name + Formal Parameter Types (in order)

Return types, access modifiers, optional specifiers ( static , final , synchronized ), and throws clauses are part of the method declaration, but not part of the signature.

Valid Method Declaration Format [access_modifier] [specifiers] <return_type> <methodName>([parameters]) [throws_clause] { ... }

A method must declare a return type (or void ). A constructor does not declare any return type. If a method shares the class name but declares a return type ( public void User() ), it is a regular method, not a constructor.

Specifiers ( static , final , synchronized , native ) can appear in any order relative to each other, but must precede the return type.

5. Method Overloading Mechanics

Method overloading occurs when two or more methods in the same class share the exact same method name but possess different parameter lists (differing in count, types, or order). public void compute(int a, double b) {} // Method 1

• public void compute(double a, int b) {} // Method 2: Overloaded (different parameter order)
• public int compute(int a) { return a; } // Method 3: Overloaded (different parameter count)
• // public int compute(int a, double b) {} // COMPILE ERROR: Duplicate signature with Method 1

Warning

Changing only the return type, access modifier, or throws list does not constitute an overload. If the parameter types match an existing method, the compiler flags a duplicate method error.

Overload Resolution Precedence

When resolving which overloaded method to invoke, the Java compiler processes arguments through four distinct phases in strict hierarchical order: Tier 1: Exact Match / Subtyping (widening reference types without boxing)

• ↓
• Tier 2: Primitive Widening (byte -> short -> int -> long -> float -> double)
• ↓
• Tier 3: Autoboxing / Unboxing (int <-> Integer)
• ↓
• Tier 4: Variable-Length Arguments (Varargs: ...) public class OverloadDemo {
• static void process(long n) { System.out.print("long "); }
• static void process(Integer n) { System.out.print("Integer "); }
• static void process(int... n) { System.out.print("varargs "); }

• public static void main(String[] args) {
• int x = 42;
• process(x); // Outputs: long (Primitive widening beats boxing & varargs)
• }
• }

Key Rule on Widening and Boxing: Java will widen and then box? No. The compiler will widen a primitive to another primitive, or box a primitive to its wrapper. It will never widen a primitive and then box it to a different wrapper (e.g., an int cannot become a Long ). However, once boxed, the wrapper can be widened to an interface or superclass (e.g., int -> Integer -> Number -> Object ).

6. Variable-Length Arguments (Varargs)

Varargs ( Type... name ) allows a method to accept zero, one, or multiple arguments of a specified type.

Constraints on Varargs

Position : A varargs parameter must be the last parameter in the formal parameter list.

Count : There can be at most one varargs parameter per method.

Representation : Inside the method body, the varargs parameter is treated as a standard array ( Type[] ). public void log(String prefix, int... values) { // Legal

• System.out.println(prefix + ": Length = " + values.length);
• }

• // public void bad1(int... a, String... b) {} // COMPILE ERROR: Only one varargs permitted
• // public void bad2(int... a, String prefix) {} // COMPILE ERROR: Varargs must be last

When passing zero arguments to log("Data") , values is an empty array ( new int[0] ), not null . If a method is overloaded with both a fixed-parameter version and a varargs version (e.g., test(int a) and test(int... a) ), calling test(10) invokes the exact-match fixed version.