1Z0-829 — Oracle Java SE 17 Developer Exam Blueprint
Independent exam blueprint for Oracle Java SE 17 Developer (1Z0-829) candidates reviewing Java SE 17 language, APIs, modules, streams, concurrency, I/O, JDBC, and exam readiness.
How to Use This Exam Blueprint
Use this checklist as a practical study map for the Oracle Java SE 17 Developer (1Z0-829) exam from Oracle. It is not a replacement for hands-on coding or official exam information. It is designed to help you decide whether you can recognize, write, debug, and reason about Java SE 17 code under exam conditions.
For each topic area, ask:
- Can I predict the output without running the code?
- Can I identify compile-time errors versus runtime exceptions?
- Can I choose the best API, syntax form, or design approach for a scenario?
- Can I explain why the other options are wrong?
- Can I handle edge cases involving scope, access, generics, streams, modules, exceptions, and concurrency?
Topic-area readiness table
| Readiness area | What to review | You are ready when you can… |
|---|---|---|
| Java basics and program structure | Source files, packages, imports, main, comments, identifiers, primitive types, wrappers, literals, var | Determine what compiles, what runs, and how variables are typed and initialized |
| Operators and expressions | Numeric promotion, assignment, compound assignment, equality, relational operators, logical operators, precedence, short-circuiting | Evaluate expressions accurately and identify subtle type conversions |
| Control flow | if, else, loops, break, continue, labels, switch statements, switch expressions | Predict branch selection, fall-through behavior, loop execution, and switch result typing |
| Object-oriented design | Classes, objects, constructors, encapsulation, inheritance, overriding, overloading, polymorphism | Trace object creation, method dispatch, field hiding, access rules, and initialization order |
| Interfaces, enums, records, sealed types | Interface members, default/static/private methods, enums, records, sealed classes/interfaces, permits | Recognize valid declarations and select the right type construct for a scenario |
| Exceptions | Checked and unchecked exceptions, try, catch, finally, multi-catch, try-with-resources, suppressed exceptions | Determine required handling, catch order, resource closing, and final outcome |
| Arrays, collections, and generics | Arrays, List, Set, Map, queues, sorting, generics, wildcards, type inference | Choose suitable collection types and diagnose unsafe or invalid generic code |
| Lambdas and functional interfaces | Lambda syntax, method references, built-in functional interfaces, effectively final variables | Match lambdas to target types and reason about captured variables |
| Streams and Optional | Stream pipeline lifecycle, lazy operations, terminal operations, primitive streams, collectors, Optional | Predict stream output, side effects, short-circuiting, and collector results |
| Date/time, localization, formatting | java.time, periods, durations, time zones, formatting/parsing, locale-sensitive APIs | Choose correct temporal types and avoid mutable/legacy date assumptions |
| I/O and NIO.2 | Path, Files, readers/writers, streams, serialization concepts where relevant, file traversal | Select APIs for file operations and reason about path normalization and checked exceptions |
| Concurrency | Threads, Runnable, Callable, executors, synchronization, locks, atomics, concurrent collections, parallel streams | Identify race conditions, ordering risks, deadlock cues, and safe coordination choices |
| JDBC | Connections, statements, prepared statements, result sets, transactions, resource handling | Read JDBC code, spot resource leaks, choose safe query execution patterns |
| Modules | module-info.java, requires, exports, services, classpath vs module path concepts | Explain module visibility and diagnose missing readability or accessibility |
| Security and maintainability | Immutability, input validation, encapsulation, secure resource handling, SQL injection avoidance | Identify safer designs and risky coding patterns in Java applications |
Java basics and declarations
Core checks
- Identify legal and illegal identifiers, including reserved words and contextual keywords.
- Distinguish top-level, member, local, and anonymous declarations.
- Know which declarations can use access modifiers.
- Recognize valid
mainmethod signatures. - Understand default initialization for fields and array elements.
- Know that local variables must be definitely assigned before use.
- Use
varonly where local variable type inference is allowed. - Distinguish primitive types from wrapper types.
- Recognize autoboxing, unboxing, and where
NullPointerExceptioncan occur. - Understand String immutability and string pool behavior at a practical level.
Common traps
| Trap | What to check |
|---|---|
var x = null; | Cannot infer a type from null alone |
var as a field or method parameter | Not allowed for those declaration positions |
| Uninitialized local variable | Compile-time error |
| Uninitialized instance field | Receives default value |
| Wrapper comparison | == compares references except after unboxing or for certain cached values; prefer .equals() for value comparison |
| String concatenation | If either operand is a String, + performs concatenation from that point |
Can you do this?
var a = 10;
var b = 10L;
var c = a + b;
System.out.println(((Object) c).getClass().getSimpleName());
You should be able to identify the inferred type of c and explain numeric promotion.
Operators, expressions, and numeric behavior
| Topic | Readiness prompt |
|---|---|
| Unary operators | Can you explain pre-increment versus post-increment in compound expressions? |
| Numeric promotion | Can you predict the result type of arithmetic involving byte, short, char, int, long, float, and double? |
| Compound assignment | Can you explain why x += y may compile when x = x + y does not? |
| Equality | Can you distinguish primitive equality, reference equality, and object equality? |
| Logical operators | Can you identify when right-hand expressions are skipped by && and ` |
| Bitwise operators | Can you distinguish &, ` |
| Precedence | Can you evaluate expressions without relying on visual intuition? |
Final-review expression checks
- I can determine when a narrowing cast is required.
- I can identify integer division versus floating-point division.
- I can explain
NaN, infinity, and comparison behavior for floating-point values at a basic level. - I can trace side effects in expressions with
++,--, assignment, and method calls. - I can spot unreachable code caused by constant expressions or unconditional flow transfer.
Control flow and switch readiness
What to know
if/elsebinding and nested conditionals.- Loop types:
for, enhancedfor,while,do while. - Labels with
breakandcontinue. - Switch statements versus switch expressions.
caselabels,default,yield, and exhaustiveness expectations where applicable.- Fall-through behavior in traditional switch statements.
Switch readiness table
| Construct | Be ready to decide |
|---|---|
| Switch statement | Does it require break to avoid fall-through? |
| Switch expression | Does every path produce a value? |
| Arrow case | Does it avoid fall-through? |
| Colon case | Is yield needed in a switch expression block? |
| Enum switch | Are case labels written correctly without unnecessary qualification? |
| String switch | Is matching based on value equality? |
| Null selector | Could a NullPointerException occur? |
Example review
int score = 2;
String result = switch (score) {
case 1 -> "low";
case 2, 3 -> "mid";
default -> {
yield "high";
}
};
You should be able to explain why this compiles, what value is assigned, and how it differs from a traditional switch statement.
Object-oriented programming
Class and object readiness
- Trace constructor chaining with
this()andsuper(). - Know that a constructor does not have a return type.
- Identify when the compiler inserts a default constructor.
- Understand initialization order: static fields/blocks, instance fields/blocks, constructors.
- Distinguish method overloading from overriding.
- Apply access modifiers:
private, package access,protected,public. - Recognize legal and illegal uses of
static,final, andabstract. - Understand field hiding versus method overriding.
- Predict dynamic dispatch for overridden instance methods.
- Know that static methods are hidden, not overridden.
- Understand covariant return types in overriding.
OOP decision table
| Scenario | Best reasoning path |
|---|---|
| Same method name, different parameter list | Overloading resolution at compile time |
| Subclass method with same signature | Overriding, subject to access and exception rules |
| Field accessed through superclass reference | Field selection based on reference type |
| Instance method called through superclass reference | Method dispatch based on runtime object |
private method with same name in subclass | Not overriding |
final method in superclass | Cannot be overridden |
| Constructor calls overridable method | Risky; subclass state may not be initialized yet |
Initialization-order check
class Parent {
static { System.out.print("A"); }
{ System.out.print("B"); }
Parent() { System.out.print("C"); }
}
class Child extends Parent {
static { System.out.print("D"); }
{ System.out.print("E"); }
Child() { System.out.print("F"); }
}
You should be able to predict output order when new Child() is executed after class loading considerations are applied.
Interfaces, enums, records, and sealed types
Interfaces
- Identify implicit
public static finalfields. - Identify implicit
public abstractmethods. - Use default methods correctly.
- Use static interface methods correctly.
- Recognize private interface methods used to share default-method logic.
- Resolve conflicts between inherited default methods.
- Know that a class implementation wins over an interface default method.
Enums
- Know enum constants are instances of the enum type.
- Recognize legal enum constructors and fields.
- Understand that enum constructors are not called directly by application code.
- Use
values(),valueOf(),name(), andordinal()cautiously. - Avoid relying on
ordinal()for stable business meaning.
Records
- Recognize record components and generated accessors.
- Understand that records are intended as transparent carriers for immutable data.
- Know how compact constructors validate or normalize input.
- Identify restrictions on record inheritance.
- Distinguish component accessors from JavaBean-style getters.
record Account(String id, int balance) {
Account {
if (balance < 0) throw new IllegalArgumentException();
}
}
You should be able to explain when the compact constructor runs and how component assignment works.
Sealed classes and interfaces
- Recognize
sealed,non-sealed, andfinal. - Understand the role of
permits. - Know that permitted subclasses must declare an allowed continuation modifier.
- Apply sealed types to constrained inheritance scenarios.
- Distinguish sealed hierarchies from enums and records.
Exceptions and resource handling
Exception-readiness table
| Area | Be ready to answer |
|---|---|
| Checked exceptions | Must they be caught or declared? |
| Unchecked exceptions | Can they occur without declaration? |
| Catch ordering | Is a subclass caught before its superclass? |
| Multi-catch | Are alternatives unrelated and non-assignable? |
finally | Does it run after normal completion, return, or thrown exception? |
| Try-with-resources | Are resources closed automatically in reverse order? |
| Suppressed exceptions | What happens if both body and close operation throw? |
| Rethrowing | Is the declared type broad enough? |
Can you do this?
- Given a method body, identify every checked exception that must be handled or declared.
- Given nested
try/catch/finally, determine the final output and thrown exception. - Given try-with-resources, determine resource closing order.
- Explain why
catch (Exception e)beforecatch (IOException e)is invalid. - Identify when a
finallyblock can mask a prior exception or return value.
Resource handling example
try (var in = Files.newBufferedReader(path)) {
return in.readLine();
}
You should know why this is safer than manually closing the reader and which checked exceptions may matter.
Arrays, collections, and generics
Arrays
- Create, initialize, and access one-dimensional and multidimensional arrays.
- Distinguish array length from collection size.
- Recognize array covariance and possible
ArrayStoreException. - Know default element values.
- Use enhanced
forloops without assuming they can replace array elements by reassigning the loop variable.
Collections
| Type | Key exam-readiness points |
|---|---|
List | Ordered, index-based, allows duplicates |
Set | Unique elements, equality/hash behavior matters |
Queue / Deque | Head/tail operations, method pairs that throw exceptions vs return special values |
Map | Key-value structure; not a Collection; key equality matters |
ArrayList | Fast random access, resizing behavior conceptually |
HashSet / HashMap | Depends on equals() and hashCode() |
TreeSet / TreeMap | Sorted order; natural ordering or comparator required |
Collections utility | Sorting, searching, unmodifiable views, factory-style helpers where applicable |
Generics
- Understand type parameters on classes, interfaces, methods, and constructors.
- Identify valid bounded type parameters.
- Use upper-bounded wildcards:
? extends Type. - Use lower-bounded wildcards:
? super Type. - Recognize when a wildcard allows reading, writing, or neither safely.
- Understand type erasure at a practical exam level.
- Identify raw type risks and unchecked warnings.
- Know that generic type parameters cannot use primitive types directly.
Wildcard decision prompt
| Need | Likely form |
|---|---|
| Read items as a base type from a producer | ? extends Base |
| Add subclass instances to a consumer | ? super Subclass |
| Both read and write exact type safely | Concrete generic type such as List<Employee> |
| Unknown type, mostly inspect size or clear | ? |
A common memory aid is producer extends, consumer super, but do not use it mechanically. Always check what the code actually reads and writes.
Lambdas, method references, and functional interfaces
Functional interface readiness
- Identify a functional interface by its single abstract method.
- Ignore
Objectmethods when counting abstract methods. - Recognize
@FunctionalInterfaceas a compile-time validation aid. - Match lambda parameter and return types to the target functional interface.
- Know that lambda variables must be final or effectively final.
- Distinguish expression lambdas from block lambdas.
- Recognize valid method references.
Common built-in functional interfaces
| Interface | Shape | Typical use |
|---|---|---|
Predicate<T> | T -> boolean | Filtering |
Consumer<T> | T -> void | Side effects |
Supplier<T> | () -> T | Lazy creation |
Function<T,R> | T -> R | Mapping |
UnaryOperator<T> | T -> T | Same-type transformation |
BinaryOperator<T> | (T,T) -> T | Reduction |
BiPredicate<T,U> | (T,U) -> boolean | Two-argument test |
BiConsumer<T,U> | (T,U) -> void | Two-argument side effect |
BiFunction<T,U,R> | (T,U) -> R | Two-argument mapping |
Method reference checks
| Form | Example pattern |
|---|---|
| Static method | Type::staticMethod |
| Instance method on a particular object | object::instanceMethod |
| Instance method on an arbitrary object of a type | Type::instanceMethod |
| Constructor | Type::new |
Can you decide whether this compiles?
Predicate<String> p = String::isBlank;
Function<String, Integer> f = String::length;
Supplier<StringBuilder> s = StringBuilder::new;
You should be able to map each method reference to the functional interface method signature.
Streams, collectors, and Optional
Stream pipeline readiness
- Distinguish source, intermediate operations, and terminal operations.
- Know that many intermediate operations are lazy.
- Recognize single-use stream behavior.
- Predict short-circuiting with operations such as
findFirst,findAny,anyMatch,allMatch,noneMatch,limit. - Distinguish
mapfromflatMap. - Understand primitive streams:
IntStream,LongStream,DoubleStream. - Use
summaryStatistics,average,sum,min, andmaxappropriately. - Recognize when terminal operations return
Optional. - Identify side-effect risks in stream pipelines.
Collector readiness table
| Collector pattern | Be ready to use or recognize |
|---|---|
toList() / toSet() | Collect stream elements into a collection |
joining() | Combine strings |
counting() | Count elements |
groupingBy() | Create groups by classifier |
partitioningBy() | Split into true/false buckets |
mapping() | Adapt values inside a downstream collector |
reducing() | Combine values with accumulator logic |
toMap() | Build maps and handle duplicate-key scenarios |
Stream traps
| Trap | Why it matters |
|---|---|
| Reusing a consumed stream | Runtime failure |
Assuming peek always runs | It runs only as part of a terminal operation and may be optimized with short-circuiting |
| Mutating shared state | Especially risky with parallel streams |
Confusing findFirst and findAny | Ordering expectations differ, especially in parallel |
Using Optional.get() blindly | Can throw if empty |
Assuming allMatch on empty stream is false | It is true due to vacuous truth |
Optional checks
- Use
isPresent,isEmpty,ifPresent,orElse,orElseGet,orElseThrow. - Explain eager evaluation of
orElseversus lazy evaluation oforElseGet. - Avoid using
Optionalas a general replacement for every nullable field. - Recognize
OptionalInt,OptionalLong, andOptionalDouble.
String value = Optional.of("java")
.filter(s -> s.length() > 10)
.orElseGet(() -> "fallback");
You should be able to explain why "fallback" is produced and when the supplier runs.
Date, time, localization, and formatting
Java time API readiness
| Type | Use when… |
|---|---|
LocalDate | Date without time or zone |
LocalTime | Time without date or zone |
LocalDateTime | Date and time without zone |
ZonedDateTime | Date and time with time zone |
Instant | Machine timestamp on the timeline |
Period | Date-based amount such as years, months, days |
Duration | Time-based amount such as seconds, nanos |
DateTimeFormatter | Formatting and parsing date/time values |
Can you do this?
- Choose between
PeriodandDuration. - Predict the result of
plusDays,plusMonths,minusWeeks, and similar methods. - Remember that date/time classes in
java.timeare immutable. - Parse and format dates using a formatter.
- Understand locale-sensitive formatting at a practical level.
- Distinguish time zone from offset.
- Recognize daylight-saving-time scenarios as a reason to use appropriate zoned types.
Formatting and localization review
- Understand that formatting can vary by
Locale. - Recognize number, currency, percent, and date/time formatting patterns.
- Know that parsing can fail and may throw runtime parsing exceptions.
- Do not assume system default locale or time zone unless the code explicitly uses it.
I/O, NIO.2, and file operations
Path and Files readiness
- Create
Pathinstances using modern APIs. - Distinguish relative and absolute paths.
- Understand
normalize,toAbsolutePath, andresolve. - Use
Files.exists,isDirectory,isRegularFile,size,copy,move,delete, and related operations conceptually. - Know which file operations commonly require exception handling.
- Read and write text using buffered readers/writers.
- Read all lines or stream lines when appropriate.
- Traverse directories with stream-returning file methods.
- Close streams from file APIs, usually with try-with-resources.
Path example
Path base = Path.of("/app/logs");
Path file = base.resolve("today.log").normalize();
You should be able to explain the resulting path conceptually and why Path operations do not necessarily touch the file system until a Files operation is used.
I/O traps
| Trap | Better exam reasoning |
|---|---|
Assuming Path creation validates file existence | Path is a path representation; file checks are separate |
Forgetting checked IOException | Many Files operations require handling or declaration |
| Leaving file streams open | Use try-with-resources |
| Confusing character streams and byte streams | Text uses readers/writers; binary data uses input/output streams |
| Assuming directory traversal order | Do not rely on unspecified ordering unless sorted explicitly |
Concurrency readiness
Core concurrency checklist
- Create tasks with
RunnableandCallable. - Understand basic
Threadlifecycle concepts. - Use executor services conceptually for task management.
- Distinguish
executefromsubmit. - Understand
Futureresult retrieval and exception wrapping at a practical level. - Identify race conditions caused by shared mutable state.
- Use synchronization to protect critical sections.
- Recognize visibility concerns and the role of
volatileat a basic level. - Understand atomic classes for simple thread-safe updates.
- Choose concurrent collections when multiple threads access shared data.
- Recognize risks of parallel streams with side effects.
- Identify deadlock clues: multiple locks acquired in inconsistent order.
Concurrency decision table
| Scenario | Safer choice |
|---|---|
| Need a result from background work | Callable with Future |
| Need shared counter updates | Atomic counter or synchronized access |
| Multiple threads update a map | Concurrent map rather than unsynchronized HashMap |
| Need to coordinate access to mutable object | Synchronization or lock discipline |
| Independent CPU-friendly stream processing | Consider parallel stream only if side effects are avoided |
| Blocking I/O tasks | Executor configuration matters conceptually; avoid assuming parallel stream is ideal |
Race-condition cue
class Counter {
private int count;
void increment() { count++; }
int get() { return count; }
}
You should be able to explain why count++ is not atomic and how simultaneous calls can lose updates.
JDBC readiness
JDBC checklist
- Understand the roles of
Connection,Statement,PreparedStatement, andResultSet. - Use try-with-resources for JDBC resources.
- Distinguish queries from updates.
- Iterate through
ResultSetusing cursor movement. - Retrieve column values by name or index.
- Understand transaction concepts: auto-commit, commit, rollback.
- Prefer
PreparedStatementfor parameterized SQL. - Recognize SQL injection risk from string concatenation.
- Know that many JDBC operations throw checked
SQLException.
Safer parameterized pattern
String sql = "select name from users where id = ?";
try (PreparedStatement ps = connection.prepareStatement(sql)) {
ps.setInt(1, userId);
try (ResultSet rs = ps.executeQuery()) {
while (rs.next()) {
System.out.println(rs.getString("name"));
}
}
}
You should be able to explain resource scope, parameter binding, and why this is safer than concatenating user input into SQL.
Modules and packaging
Module readiness
- Read a
module-info.javafile. - Understand
requiresfor module dependencies. - Understand
exportsfor making packages accessible to other modules. - Distinguish exporting a package from merely having it inside a module.
- Recognize qualified exports at a conceptual level.
- Understand
requires transitiveas exposing a dependency to downstream modules. - Understand service provider and service consumer declarations conceptually.
- Distinguish classpath-based access from module-path-based access.
- Diagnose errors caused by missing readability or non-exported packages.
Module descriptor example
module com.example.app {
requires java.sql;
exports com.example.api;
}
Readiness questions:
- What module dependency is declared?
- Which package is exported?
- Are non-exported packages accessible to other modules?
- Would code in another module automatically access internal packages?
Security, encapsulation, and maintainability
Practical secure-coding checks
| Area | Exam-ready behavior |
|---|---|
| Encapsulation | Keep fields private and expose controlled behavior |
| Immutability | Use final fields, defensive copies, and immutable types where appropriate |
| Input validation | Validate constructor and method inputs before storing or using them |
| Resource management | Close files, streams, sockets, and JDBC resources reliably |
| SQL safety | Prefer parameterized statements |
| Sensitive data | Avoid unnecessary logging or exposure |
| Exceptions | Do not swallow exceptions silently without a recovery strategy |
| Collections | Avoid exposing mutable internal collections directly |
| Inheritance | Prefer careful design; avoid overridable calls during construction |
Defensive copy prompt
If a class stores a mutable collection supplied by a caller, can you explain why this is risky?
class Team {
private final List<String> names;
Team(List<String> names) {
this.names = new ArrayList<>(names);
}
List<String> names() {
return List.copyOf(names);
}
}
You should be able to explain how this protects internal state.
Scenario and decision-point checks
Use these prompts to test whether you can apply Java knowledge, not just recall syntax.
| Scenario | Can you choose and justify? |
|---|---|
A method must accept any list of Dog or subclasses and only read values | Use an upper-bounded wildcard |
A method must add Dog objects to a destination list | Use a lower-bounded wildcard |
| A data carrier needs concise immutable state and generated accessors | Consider a record |
| A hierarchy must restrict allowed subclasses | Consider sealed types |
| Code must process many values with filtering and grouping | Use streams and collectors |
| Code must avoid SQL injection | Use PreparedStatement |
| Multiple threads update shared state | Use synchronization, atomics, or concurrent collections |
| A file must be read safely | Use NIO.2 and try-with-resources |
| Date math uses months and days | Use Period, not Duration |
| Time math uses seconds or nanoseconds | Use Duration, not Period |
| A package should be accessible outside a module | Export it in module-info.java |
| Internal implementation should stay hidden | Do not export the internal package |
Common weak areas and exam traps
| Weak area | What to drill |
|---|---|
| Compile-time versus runtime failure | For every code sample, label the failure phase before explaining output |
| Overload resolution | Practice with primitives, wrappers, varargs, inheritance, and null |
| Overriding rules | Access level, return type, checked exceptions, static methods, private methods |
| Initialization order | Static initialization, instance initialization, superclass before subclass |
| Generics wildcards | Read/write permissions with extends and super |
| Stream laziness | Know when operations actually execute |
| Optional | Avoid unsafe get() and know eager versus lazy fallback |
| Try-with-resources | Resource closing order and suppressed exceptions |
| Date/time immutability | Remember methods return new objects |
| Path operations | Separate path manipulation from file-system operations |
| Concurrent mutation | Identify non-atomic compound actions |
| Module visibility | requires and exports solve different problems |
| JDBC resources | Close nested resources and use parameter binding |
“Can you do this?” master checklist
Before final review, you should be able to complete these tasks without looking up syntax.
Language and syntax
- Predict output for code using operators, casts, wrappers, and strings.
- Identify whether code compiles when
varis used. - Trace loop execution with labels,
break, andcontinue. - Convert between traditional switch syntax and switch expression syntax.
- Explain numeric promotion in mixed-type arithmetic.
Object-oriented Java
- Trace constructor and initialization order.
- Determine which overloaded method is selected.
- Determine which overridden method executes at runtime.
- Explain why fields do not behave polymorphically like overridden methods.
- Validate interface, enum, record, and sealed-type declarations.
APIs and data handling
- Choose the right collection for ordering, uniqueness, keys, or sorting.
- Write or read generic method signatures with bounded type parameters.
- Match lambdas and method references to functional interfaces.
- Predict stream pipeline results, including short-circuiting.
- Use collectors for grouping, partitioning, joining, and map creation.
- Choose appropriate date/time types and formatters.
I/O, database, modules, and concurrency
- Read and write file examples using
PathandFiles. - Identify required exception handling for I/O and JDBC operations.
- Read JDBC code using
PreparedStatementandResultSet. - Explain transaction commit and rollback at a practical level.
- Read a module descriptor and determine accessibility.
- Identify race conditions and safer concurrency alternatives.
Final-week review checklist
Seven to five days out
- Revisit every missed practice question and classify the miss: syntax, API, concept, careless reading, or time pressure.
- Build a one-page list of personal traps, especially around generics, streams, exceptions, and OOP.
- Recode small examples for topics you keep missing.
- Review Java SE 17 language features that differ from older Java versions.
- Practice predicting output without an IDE.
Four to two days out
- Do mixed-topic timed practice.
- For each wrong answer, write the exact rule that would have prevented the mistake.
- Review method signatures for common functional interfaces and stream operations.
- Drill compile-time error recognition.
- Review try-with-resources, module descriptors, JDBC patterns, and concurrency examples.
Final day
- Stop trying to learn large new topics.
- Review your personal trap sheet.
- Re-read concise examples for switch expressions, records, sealed classes, streams, generics, and exceptions.
- Practice slowing down on questions that ask “which statements are true” or “what is the result.”
- Confirm you can explain why each incorrect option is incorrect.
Practical next step
Use this Exam Blueprint to choose your next practice set. Start with your weakest readiness area, answer mixed code-based questions, then review every miss until you can state the Java rule, predict the behavior, and recognize the trap in a new example.