1Z0-831 sample questions — 25 answered and explained

Multiplicative operators (* / %) have higher precedence than additive ones (+ -), and operators of equal precedence associate left to right.

The expression groups as a + ((b * c) % 5) - (c / a). Each wrong value comes from one grouping mistake: % before * (12), + before * (-2), or % applied to the whole sum (4).

1. Group the multiplicative operators first: (b * c) % 5 and c / a.
2. Within that level, go left to right: 12, then 12 % 5 = 2.
3. c / a = 2.
4. Finish left to right: 2 + 2 - 2 = 2.

Exam tip: * / % bind tighter than + -, and equal-precedence operators run left to right.

+ evaluates left to right and means numeric addition until one operand is a String; char participates as a number.

Each + is decided by the types of its two operands at that point. Before the first String, numbers (and chars) are added; after it, every + concatenates. 'A' + 1 is therefore 66, and 1 + 2 is 3, but everything after "x" or "" is appended text.

1. Group + left to right: ((((a + b) + "x") + a) + b).
2. Before the String: 1 + 2 = 3; after it: append 1 then 2.
3. Line 2: 'A' + 1 is int addition, 65 + 1 = 66.
4. Then + "" turns it into text: 66, then append A and 1.

Exam tip: + adds until a String appears, then concatenates; a char before that point is a number.

&& and || short-circuit; the boolean & and | operators always evaluate both operands.

The first expression stops after x > 0 is false, so its ++x never runs. The second uses |, which evaluates both sides even when the left is false, so ++x runs once in total and x ends at 1.

1. Evaluate r: x > 0 is false, && stops, r = false, x = 0.
2. Evaluate s: | runs both sides; x > 0 is false.
3. ++x makes x 1, and 1 > 0 is true, so s = true.
4. Print r, s and x: false true 1.

Exam tip: && and || may skip the right side; & and | never do.

A switch expression must produce a value for every possible selector value. For int, char, String and similar selectors that means a default (or an unconditional pattern).

The compiler checks exhaustiveness of every switch expression. Three int constants cover only three of about four billion values, so without default the code does not compile, even though level happens to be 2. The tempting answer mid ignores the compile-time check; null and MatchException imagine a runtime fallback that does not exist for this case.

1. Identify the construct as a switch expression (its value is assigned).
2. Check whether the labels cover every possible int value.
3. They do not, and there is no default.
4. So compilation fails before any output.

Exam tip: A switch expression on int or String needs default; exhaustiveness is checked at compile time.

A switch expression on an enum is exhaustive when it lists every constant, so default is optional. Exhaustiveness does not cover null: a switch with no case null throws NullPointerException when the selector is null.

Two facts combine here. First, S, M and L are all covered, so the switch expression compiles without default. Second, null is never matched by constant labels or by default; unless the switch has case null, a null selector throws NullPointerException. So the loop prints 9 for Size.L and then fails on null.

1. Check exhaustiveness: every Size constant has an arm, so it compiles.
2. First element Size.L returns 9, which is printed.
3. Second element is null and the switch has no case null.
4. A null selector without case null throws NullPointerException.

Exam tip: Listing every enum constant makes a switch expression exhaustive, but only case null handles null.

A class is initialized lazily on its first active use (such as reading a non-constant static field), and its static initializers run exactly once.

main prints start. The expression Config.mode reads a static field that is not a compile-time constant, so the JVM initializes Config at that point: its static block sets mode and prints load. The value prod is then printed. The second read finds Config already initialized, so only prod is printed again.

1. Main prints start before touching Config.
2. The first read of a non-constant static field initializes Config.
3. The static block runs once: prints load and sets mode.
4. Later reads do not re-run it.

Exam tip: Class initialization is lazy and happens once: on first active use, never again.

A constructor has no return type. Adding one, even void, turns the declaration into a method with the class's name.

Because void Lamp() declares a return type, it is a method, not a constructor. Lamp then declares no constructor, so the compiler supplies a default one. new Lamp() runs only the field initializer on = false; the method Lamp() is never invoked. The program prints false.

1. Check each member named Lamp for a return type.
2. void Lamp() has one, so it is a method.
3. With no declared constructor, the default constructor is used.
4. Only the field initializer runs: on is false.

Exam tip: No return type means constructor; any return type, even void, means method.

A compact canonical constructor omits the parameter list; its implicit parameters can be validated or reassigned, and the fields are assigned from them automatically at the end.

Range { ... } is a compact canonical constructor. Its parameters lo and hi start as 9 and 2. The body swaps them, so lo is 2 and hi is 9. After the body completes, the compiler-inserted assignments this.lo = lo and this.hi = hi store the swapped values. toString prints Range[lo=2, hi=9].

1. Recognise the compact canonical constructor (no parameter list).
2. Trace the body: 9 > 2, so the parameters are swapped.
3. Fields are assigned from the parameters after the body ends.
4. Format with the record toString.

Exam tip: In a compact constructor you normalise the parameters; Java assigns the fields afterwards.

In a compact canonical constructor the fields are assigned implicitly at the end; assigning this.field yourself is a compile-time error.

Inside a compact constructor, the record fields are final and are assigned automatically after the body. The explicit statement this.celsius = celsius would assign a final field the compiler is about to assign, so javac reports "cannot assign a value to final variable celsius". Writing celsius = ... (the parameter) would be legal; writing this.celsius is not. The validation itself is fine.

1. Identify the compact canonical constructor.
2. Find any statement assigning this.component.
3. Recall that fields are assigned implicitly, so explicit assignment is an error.
4. The program does not compile.

Exam tip: Compact constructor: touch the parameters, never this.field.

A return expression is evaluated before finally runs; finally can change variables but not a value that has already been computed for return.

Executing return count evaluates the expression to 10 and keeps that value as the pending result. finally then executes count += 5, so the static field becomes 15, but the pending result is a copy of the int and stays 10. Because finally completes normally, the method returns 10. main prints first (10) and the field (15). 15 15 assumes finally changes what is returned; it would only do so with its own return statement.

1. Evaluate the return expression when it executes: 10.
2. Run finally: count becomes 15.
3. finally completes normally, so the pending 10 is returned.
4. Print first and the updated field.

Exam tip: The return value is fixed when return executes; finally changes variables, not that value.

When both the try-with-resources body and close() throw, the body's exception propagates and the close() exception is suppressed onto it.

The body throws IllegalArgumentException("query"). Before the catch can run, the resource is closed, and close() throws IllegalStateException("close"). Try-with-resources keeps the first exception as primary and calls addSuppressed with the second, so the catch sees query with getSuppressed().length equal to 1. A plain try/finally would lose one of the two; try-with-resources keeps both.

1. Identify the first exception: query from the body.
2. Close the resource: close() throws close.
3. Attach the close exception as suppressed on the primary.
4. Print the primary message and the suppressed count.

Exam tip: In try-with-resources the body's exception wins; close() failures ride along in getSuppressed().

add(index, e) inserts and shifts later elements right; set(index, e) replaces and returns the old element; indexOf returns -1 when the element is absent.

The list is [A, C] and add(1, "B") inserts B at index 1, giving [A, B, C]. set(2, "D") replaces C with D and returns C, which is stored in old. The list is now [A, B, D], and indexOf("C") returns -1 because C is gone.

1. Apply each add, remembering that add(index, e) shifts elements.
2. Apply set and note the value it returns.
3. Look up indexOf in the final list.
4. Assemble the output.

Exam tip: set replaces and returns the old element; add(index, e) inserts.

To remove elements while traversing a list, use removeIf or the iterator's own remove. Removing through the list during an enhanced for loop fails fast, and a forward index loop skips the element that shifts into the removed slot.

removeIf and Iterator.remove both remove xa, xb and xd and leave [c]. The enhanced for loop calls list.remove(s) while its hidden iterator is active, so the iterator's next call throws ConcurrentModificationException. The forward index loop removes xa at index 0, xb shifts into index 0, and the loop continues at index 1, so xb survives. removeAll matches by equals, not by prefix, so it removes nothing.

1. Ask which fragments use the iterator or a bulk predicate.
2. Check enhanced for loops for structural changes made through the list.
3. For index loops, trace what shifts after a removal.
4. Check whether a bulk method matches by equals or by predicate.

Exam tip: Remove while iterating with removeIf or Iterator.remove, never with list.remove inside for-each.

Stream.iterate(seed, hasNext, next) emits the seed first and stops at the first value that fails hasNext, like a for loop.

The three-argument iterate behaves like for (n = 1; n < 30; n = n * 3). It emits 1, 3, 9 and 27, then computes 81, which fails n < 30, and the stream ends. skip(1) discards the first emitted element, the seed 1, leaving 3, 9 and 27. Answers containing 81 treat the predicate as checked after emitting; the answer ending at 9 applies the bound too early.

1. Expand iterate as a loop: 1, 3, 9, 27; 81 fails n < 30.
2. Remember that the seed itself is the first element.
3. Apply skip(1): drop 1.
4. Print 3 9 27 with trailing spaces.

Exam tip: Three-argument iterate is a for loop in stream form: seed first, predicate checked before every element.

Stream.generate and two-argument iterate produce infinite streams; limit counts only the elements that reach it, so a filter upstream that never matches makes the pipeline run forever.

Stream.generate(() -> "x") never runs out. limit(2) would end the stream after two elements, but it counts elements that arrive at it, not elements generated. Because "x".length() > 1 is false, filter discards every element, limit never sees one, and forEach keeps pulling forever. Nothing is printed and end is never reached. No elements are buffered, so there is no OutOfMemoryError; the program simply runs until it is killed.

1. Recognise generate as an infinite source.
2. Evaluate the filter for x: length 1, rejected every time.
3. Note that limit counts only elements that pass the filter.
4. Conclude that the terminal operation never completes.

Exam tip: limit bounds what reaches it, not what the source produces: put limit before a filter that might never match.

requires static makes a dependency mandatory at compile time but optional at run time, and the module is resolved only if something else requires it or it is added (for example with --add-modules).

Being on the module path is not the same as being resolved. The module system resolves the root module (app) and its non-static requires. metrics is reached only through requires static, so it stays out of the module graph. main prints start, then the reference to Counter cannot be loaded and NoClassDefFoundError is thrown. Launching with --add-modules metrics would print inc.

1. Note the directive: requires static metrics.
2. Recall that static dependencies are not followed during resolution.
3. metrics is therefore not in the boot layer despite being in out.
4. Lazy loading means start prints before the failed Counter lookup.

Exam tip: On the module path is not in the graph: a requires static module must be resolved by something else, such as --add-modules.

requires static declares a dependency that is mandatory at compile time and optional at run time.

app needs to read annotations so javac can resolve the annotation types, but the deployed application must not depend on it. requires static does exactly that. A plain or transitive requires makes resolution fail when the module is absent, and uses has nothing to do with readability.

1. Separate the two phases: needed to compile, not needed to run.
2. Match that to requires static.
3. Reject directives that make the module mandatory at run time.

Exam tip: Compile-time only dependency: requires static.

shutdown() starts an orderly shutdown: queued tasks still run, but new submissions are rejected.

f.get() waits for the first task, so 1 is printed first. After shutdown(), isShutdown() is true. Any later execute() or submit() call is rejected, and the default policy throws RejectedExecutionException to the caller, main, which ends the program before end is printed.

1. The first task finishes before shutdown: 1 is printed.
2. isShutdown() is true right after shutdown().
3. Recall that a shut-down executor rejects new tasks.
4. The rejection throws RejectedExecutionException in main.

Exam tip: After shutdown(), submitting a task throws RejectedExecutionException.

shutdownNow() interrupts actively running tasks and returns the tasks that were still waiting in the queue.

The latch ensures the first task is running before shutdownNow() is called. shutdownNow() interrupts the worker, so Thread.sleep throws InterruptedException and interrupted is printed. The second and third tasks were still queued; shutdownNow() removes them and returns them as a List<Runnable> of size 2. awaitTermination lets the first task finish its catch block before main prints the size.

1. The latch proves task one has started.
2. shutdownNow() interrupts the running worker: interrupted is printed.
3. Queued tasks are drained and returned, not executed.
4. Two tasks were waiting, so the list size is 2.

Exam tip: shutdown() lets queued tasks finish; shutdownNow() interrupts running ones and hands back the queue.

newSingleThreadExecutor runs tasks sequentially in submission order, and ExecutorService.close() waits for submitted tasks.

Two facts decide the output. A single-thread executor processes its queue one task at a time, in order, so the digits are 1, 2, 3. ExecutorService has been AutoCloseable since Java 19; close() performs an orderly shutdown and waits for the tasks to complete. Only then does main print !.

1. Check compilation: n is effectively final and the executor is AutoCloseable.
2. One worker thread means tasks run in submission order.
3. close() at the end of try waits for those tasks.
4. So ! prints after 123.

Exam tip: try-with-resources on an ExecutorService waits for its tasks; a single-thread executor keeps them in order.

PrintWriter autoflush (the true argument) flushes on println, printf and format only.

PrintWriter(Writer out, boolean autoFlush) flushes its output when println, printf or format is called. print("a") stays buffered, println("b") flushes "ab" and a line separator to the file, and print("c") is buffered again. The reader therefore sees one line, ab, and then end of file. c is written only when pw.close() runs at the end. Choosing <abc> means treating autoflush as flush-after-every-call.

1. autoFlush is true, but only println, printf and format trigger it.
2. print("a") is buffered; println("b") flushes a, b and a newline.
3. print("c") is buffered and not yet in the file.
4. The reader finds one line: ab.

Exam tip: PrintWriter autoflush is not per-call: print() never flushes; println/printf/format do.

A PrintWriter around System.out buffers output and must be flushed when autoflush is off.

new PrintWriter(OutputStream) wraps the stream in a BufferedWriter and sets autoFlush to false. println("ready") goes into that buffer. Nothing calls pw.flush() or pw.close(), and the JVM does not flush user-level buffers on exit, so ready is lost. System.out is a PrintStream that the JVM sets up to flush on println, so done appears. The code compiles because PrintWriter methods do not throw IOException.

1. PrintWriter(OutputStream) has autoflush off.
2. println("ready") is held in its buffer.
3. Nothing flushes or closes pw before main ends.
4. System.out.println("done") is written normally.

Exam tip: Wrap System.out in a PrintWriter with autoflush (new PrintWriter(System.out, true)) or flush it yourself.

PrintStream methods swallow IOException, except write(byte[]), which is declared throws IOException.

PrintStream (the type of System.out) is designed not to throw IOException: print, println, printf, write(int) and write(byte[], int, int) set an internal error flag instead. The exception is write(byte[]): the Java 14 override is declared throws IOException to match OutputStream, which is why writeBytes(byte[]) was added alongside it. System.in is a plain InputStream, so its read methods and close() declare the checked IOException. Running each option: write(65) prints A, writeBytes(b) prints Hi, the other three fail with "unreported exception IOException; must be caught or declared to be thrown".

1. System.out is a PrintStream; System.in is an InputStream.
2. PrintStream's own methods report errors via checkError(), not exceptions.
3. write(byte[]) is declared throws IOException, like OutputStream.write(byte[]).
4. InputStream read methods and close() declare IOException too.

Exam tip: System.out methods don't throw checked exceptions, except write(byte[]); use writeBytes(byte[]) instead.

A loaded bundle's parent chain is built by removing parts of its own locale, ending at the base bundle.

Shop_fr_CA exists, so it is the bundle returned. Its parents are Shop_fr and then Shop, and getString or keySet sees keys from all three. The default locale's files (Shop_en_US and Shop_en) are only tried when no candidate for fr_CA exists, and Shop_fr_FR is a sibling for another country, not an ancestor.

1. Find the most specific existing bundle for fr_CA: Shop_fr_CA.
2. Drop the country to get the parent Shop_fr.
3. Drop the language to reach the base bundle Shop.
4. Ignore the default locale: it is a fallback only when the requested locale finds nothing.

Exam tip: Parents come from trimming the found bundle's locale; siblings and the default locale stay out.

For each candidate bundle name, getBundle looks for a class first and a .properties file second; ListResourceBundle values can be any object.

The candidate name Labels_en matches both a class and a property file. The default ResourceBundle.Control tries the class format before the properties format, so the ListResourceBundle subclass is loaded and the file is ignored. title is "Catalogue (class)" and getObject("pageSize") returns the Integer 25, printed as 25.

1. Both candidates have the name Labels_en, so precedence decides.
2. The default lookup tries java.class before java.properties.
3. The ListResourceBundle supplies title as Catalogue (class).
4. getObject returns the stored Integer without a cast, printed as 25.

Exam tip: Same bundle name as a class and a file? The class wins.