Use this for last-mile review. The goal is not to relearn Java. The goal is to stop the avoidable misses that come from skipping one type, one bound, or one API contract.
Read every snippet in this order
- Does it compile?
- What is the exact declared type?
- Is the issue language legality, collection/stream contract, concurrency rule, or module rule?
- Only then predict output, mutation, ordering, or exception behavior.
1Z0-830 answer sequence
Use this when the stem mixes compilation, typing, collections, streams, or modern Java features.
flowchart TD
S["Snippet or scenario"] --> C["Does it compile?"]
C --> T["What is the exact declared type?"]
T --> L["Check language, collection, or stream contract"]
L --> R["Predict output, mutation, or exception"]
Compile-vs-runtime triage
| Ask this first |
Why it matters |
| Does the code compile at all? |
many distractors disappear before runtime |
| What is the exact declared type? |
overload choice, method visibility, and generics depend on it |
| Is the object mutable, fixed-size, or unmodifiable? |
collection questions often hide here |
| Is the stream already consumed? |
streams are single-use pipelines |
| Is the exception checked or unchecked? |
the handling requirement changes immediately |
Type and assignment reminders
| Rule lane |
Fast reminder |
| declared vs runtime type |
overloads and visible members start from the declared type |
| wrapper null |
unboxing null still throws NullPointerException |
| cast |
may compile and still fail at runtime |
| local inference |
var needs an initializer and remains statically typed |
| literal defaults |
integral literals default to int; decimals default to double |
Overload and conversion order
| Rule lane |
Fast reminder |
| widening primitive |
preferred before boxing in many overload contests |
| boxing and unboxing |
legal, but can create ambiguity or NullPointerException |
| varargs |
last-resort applicability lane, not the first choice |
| compound assignment |
can include implicit cast behavior that plain assignment would reject |
var |
only for local variables with obvious initializer-driven type inference |
Java 21 feature-status map
| Feature |
Status to remember |
| records |
permanent |
| sealed classes and interfaces |
permanent |
| pattern matching for switch |
permanent in Java 21 |
| record patterns |
permanent in Java 21 |
| virtual threads |
permanent in Java 21 |
| sequenced collections |
permanent in Java 21 |
Strings, builders, and text blocks
| Feature |
Fast rule |
String |
immutable |
StringBuilder |
mutable and best for repeated in-place edits |
== on strings |
compares references, not content |
| text blocks |
multiline string syntax, still a String |
formatted() and String.format() |
locale-sensitive formatting can matter |
Flow, patterns, and records
| Topic |
Fast rule |
| switch expression |
every reachable branch must yield or throw |
| pattern variable |
only available where the match is definitely true |
| record pattern |
destructures a record shape; component order matters |
| nested pattern |
legality first, then extracted binding values |
| guard logic |
a matched shape can still fail an additional condition |
Modern OOP quick map
| Feature |
Best recall |
record |
concise immutable-style data carrier with generated members |
sealed |
restricts who may extend or implement |
| pattern matching |
combines type test and variable binding |
| default interface method |
behavior in an interface, with conflict rules |
| enum with methods |
full type, not just named constants |
OOP and hierarchy reminders
| Topic |
Better recall |
| constructor chain |
this(...) or super(...) still comes first |
| override rules |
access, return covariance, throws, and static/instance all matter |
| default-method conflict |
class wins before interface conflict logic |
| sealed hierarchy |
permitted-subtype rules are exact, not approximate |
| enum constructor |
legal and private-like by design |
Collections and generics chooser
| Requirement |
Strongest first recall |
| immutable factory list |
List.of(...) |
| fixed-size list backed by array |
Arrays.asList(...) |
| producer source |
? extends T |
| consumer sink |
? super T |
| generic type relationship |
invariance still applies |
| Java 21 ordered first/last operations |
sequenced collections awareness |
Collections and generics traps
| Trap |
Better rule |
Arrays.asList(...) is fully immutable |
it is fixed-size, not fully unmodifiable |
List.of(...) behaves like an editable list |
it is unmodifiable and rejects null |
List<Child> is-a List<Parent> |
generics are invariant |
| sequenced collections change every collection contract |
they add first/last-oriented capabilities, not universal ordering guarantees |
| wildcard direction is memorized syntax only |
extends reads safely, super writes safely |
Streams and collectors chooser
| Requirement |
Strongest first fit |
| transform each element |
map |
| keep matching elements only |
filter |
| flatten nested sources |
flatMap |
| mutable grouped result |
collector choice matters more than stream source |
| primitive pipeline |
IntStream, LongStream, DoubleStream can avoid boxing |
| parallel use |
only when operation order and shared-state assumptions still hold |
Stream and collector reminders
| Topic |
Fast rule |
| stream reuse |
illegal after a terminal operation |
| encounter order |
depends on source plus operation choice |
mapMulti |
flatten-like transformation without building nested streams explicitly |
| collector |
terminal reduction shape controller |
| parallel stream |
makes unsafe side effects even riskier |
Optional reminders
| Topic |
Fast rule |
Optional.get() |
only safe when presence is already proven |
orElse vs orElseGet |
eager versus lazy fallback evaluation |
map vs flatMap |
avoid accidental nested Optional shapes |
| Optional-as-field |
usually worse than clear domain design |
Exceptions and resources
| Rule |
Fast reminder |
| checked exception |
must be caught or declared |
| unchecked exception |
runtime family, not forced in signature |
| multi-catch |
caught variable is effectively final |
| try-with-resources |
resources close automatically in reverse declaration order |
| custom exception |
choose checked vs unchecked based on API contract intent |
Concurrency quick map
| Topic |
Fast rule |
| virtual thread |
lightweight thread for many blocking tasks |
| executor |
task-submission policy boundary |
Future / CompletableFuture |
result and orchestration contract, not just “async” buzzwords |
synchronized |
visibility plus exclusion |
| concurrent collection |
safer access pattern, not magic program correctness |
Concurrency chooser
| Requirement |
Strongest first fit |
| many blocking tasks |
virtual threads are often the first modern answer |
| explicit async composition |
CompletableFuture |
| shared mutable state guard |
coordination primitive or synchronized |
| producer-consumer work queue |
executor plus queue-aware design |
| correctness issue |
reason about visibility before performance |
Modules quick map
| Topic |
Fast rule |
JPMS requires |
declares module dependency |
JPMS exports |
exposes package to other modules |
opens |
reflective access lane |
| automatic module |
jar on module path without explicit descriptor |
| class path vs module path |
do not merge them mentally |
Final stop-before-submit prompts
- Did I separate compile from runtime?
- Did I resolve declared type before following the code?
- Did I confuse fixed-size with unmodifiable?
- Did I treat a record pattern or switch pattern like old control flow?
- Did I assume parallel means safe or faster without contract evidence?