2 packs: 15% off with code BUY2. 3 or more: 20% off with code BUY3.

Free Oracle 1Z0-829 Practice Questions

11 free Oracle 1Z0-829 practice questions from the CertStash pack of 130, each with the correct answer and a full explanation. The rule is the same for every exam: ten free on the product page, 11 free here, all 130 in the pack, and each step includes the one before it.

Question 1

Which statement is true?

  1. IllegalStateException is thrown if a thread in waiting state is moved back to runnable.
  2. A thread in waiting state consumes CPU cycles.
  3. After the timed wait expires, the waited thread moves to the terminated state.
  4. A thread in waiting state must handle InterruptedException.
Show answer and explanation

Correct answer: D. A thread in waiting state must handle InterruptedException.

The methods that put a thread into the waiting or timed waiting state, such as Object.wait, Thread.join and Thread.sleep, all declare the checked exception InterruptedException. Another thread can call interrupt on the waiting thread at any time, which ends the wait early and makes the method throw InterruptedException. Because the exception is checked, code that calls these methods must either catch it or declare it with throws, so a thread that waits must be prepared to handle InterruptedException.

Why the other options are wrong

  • A. No IllegalStateException is involved: a waiting thread returns to the runnable state normally when it is notified, interrupted or its timeout expires.
  • B. A waiting thread is parked by the JVM and is not scheduled, so it does not consume CPU cycles while it waits.
  • C. When a timed wait expires, the thread becomes runnable again (after reacquiring the monitor, if it called wait); it terminates only when its run method completes.

Question 2

Given the code fragment: List<Integer> listOfNumbers = List.of(1, 2, 3, 4, 5, 6, 7, 8, 9, 10); Which code fragment returns different values?

  1. int sum = listOfNumbers.stream().reduce(0, Integer::sum) + 5;
  2. int sum = listOfNumbers.parallelStream().reduce(0, Integer::sum) + 5 ;
  3. int sum = listOfNumbers.parallelStream().reduce((m, n) -> m + n).orElse(5) + 5;
  4. int sum = listOfNumbers.parallelStream().reduce(5, Integer::sum);
  5. int sum = listOfNumbers.stream().reduce(5, (a, b) -> a+ b);
Show answer and explanation

Correct answer: D. int sum = listOfNumbers.parallelStream().reduce(5, Integer::sum);

The identity passed to reduce must be a true identity for the accumulator, meaning that combining it with any value leaves that value unchanged; for Integer::sum that is 0. Every fragment except parallelStream().reduce(5, Integer::sum) sums the list to 55 and adds 5 exactly once, giving 60. In that parallel reduce, the list is split into chunks and every chunk starts its partial sum from the identity 5, so 5 is added once per chunk. The result is 55 plus 5 times the number of chunks (105 when the list splits into ten chunks), not 60.

Why the other options are wrong

  • A. The sequential reduce with identity 0 returns 55, and the + 5 outside the reduce makes 60.
  • B. 0 is a true identity for addition, so the parallel reduce returns 55 however the list is split, and adding 5 gives 60.
  • C. The reduce without an identity returns an Optional holding 55, so orElse(5) is not used and the result is 55 + 5 = 60.
  • E. A sequential stream starts from the identity only once, so 5 is added a single time and the result is 60.

Question 3

Which statement is true about modules?

  1. Only unnamed modules are on the module path.
  2. Automatic and named modules are on the module path.
  3. Only automatic modules are on the module path.
  4. Only named modules are on the module path.
  5. Automatic and unnamed modules are on the module path.
Show answer and explanation

Correct answer: B. Automatic and named modules are on the module path.

The module path holds two kinds of modules. A named module is a JAR or directory with a module-info.class descriptor. An automatic module is an ordinary JAR without a descriptor that is placed on the module path; the JVM gives it a name from the Automatic-Module-Name manifest entry or the JAR file name, and it exports all its packages. Code loaded from the classpath belongs to the unnamed module instead, so the module path contains named and automatic modules.

Why the other options are wrong

  • A. The unnamed module is made up of classpath content, not module path content.
  • C. Named modules with a module-info descriptor are also placed on the module path.
  • D. A plain JAR placed on the module path becomes an automatic module, so named modules are not the only kind there.
  • E. The unnamed module comes from the classpath; the module path holds named and automatic modules.

Question 4

Which statement is true?

  1. The --add-exports option is always recommended in a Java command.
  2. The --add-exports option is not allowed in a Java command.
  3. The --add-requires option is not allowed in a Java command.
  4. The --add-requires option is allowed but not recommended in a Java command.
Show answer and explanation

Correct answer: C. The --add-requires option is not allowed in a Java command.

The java launcher supports several options for breaking module encapsulation or adjusting the module graph at run time, including --add-exports, --add-opens, --add-reads and --add-modules. There is no --add-requires option: a module's dependencies can only be declared with requires directives in module-info.java, and the closest command-line equivalent is --add-reads, which adds a readability edge. Using --add-requires on a java command line is rejected as an unrecognized option, so the statement that it is not allowed is true.

Why the other options are wrong

  • A. --add-exports breaks strong encapsulation and is intended as a migration workaround, so it is not always recommended.
  • B. --add-exports is a valid option for both the java and javac commands, for example --add-exports java.base/sun.nio.ch=ALL-UNNAMED.
  • D. --add-requires does not exist at all, so it is not an allowed option on a java command line.

Question 5

Assume you have an automatic module from the module path display-ascii-0.2.jar. Which name is given to the automatic module based on the given JAR file?

  1. display-ascii-0
  2. display-ascii
  3. display.ascii
  4. display-ascii-0.2
Show answer and explanation

Correct answer: C. display.ascii

When a JAR file without a module descriptor is placed on the module path, Java derives the automatic module name from the file name. It drops the .jar extension, removes the trailing version, which starts at a hyphen followed by a digit (here -0.2), and then replaces every remaining non-alphanumeric character with a dot. The file display-ascii-0.2.jar therefore becomes display.ascii, with version 0.2, and jar --describe-module on that file reports display.ascii@0.2 automatic.

Why the other options are wrong

  • A. The whole version string -0.2 is removed, not just part of it, and the remaining hyphen is replaced with a dot.
  • B. Hyphens are not kept, because every non-alphanumeric character in the derived name is replaced with a dot, giving display.ascii (and display-ascii is not a legal module name).
  • D. The version suffix -0.2 is stripped from the file name, and hyphens become dots, so the full file name is never used as the module name.

Question 6

Given:

import java.io.Serializable;
public class Software implements Serializable {
    private String title;
    public Software(String title) {
        this.title = title;
        System.out.print("Software ");
    }
    public String toString() { return title; }
}

public class Game extends Software {
    private int players;
    public Game(String title, int players) {
        super(title);
        this.players = players;
        System.out.print("Game ");
    }
    public String toString() { return super.toString() + " " + players; }
}

import java.io.*;
public class AppStore {
    public static void main(String[] args) {
        Software s = new Game("Chess", 2);
        try (ObjectOutputStream out =
                new ObjectOutputStream(new FileOutputStream("game.ser"))) {
            out.writeObject(s);
        } catch (Exception e) {
            System.out.println("write error");
        }
        try (ObjectInputStream in =
                new ObjectInputStream(new FileInputStream("game.ser"))) {
            s = (Software) in.readObject();
        } catch (Exception e) {
            System.out.println("read error");
        }
        System.out.println(s);
    }
}

What is the result?

  1. Software Game read error
  2. Software Game Chess 0
  3. Software Game Software Game Chess 2
  4. Software Game Chess 2
  5. Software Game write error
  6. Software Game Software Game Chess 0
Show answer and explanation

Correct answer: D. Software Game Chess 2

Creating new Game("Chess", 2) runs the Software constructor through super(title) and then the Game constructor, printing Software followed by Game. The object is then serialized without error, because Game inherits Serializable from Software. During deserialization, constructors of serializable classes are not called: the JVM runs only the no-argument constructor of the first non-serializable superclass, which is Object. So nothing further is printed while reading, and the fields title and players are restored from the stream. println(s) calls Game.toString, giving Chess 2, so the output is Software Game Chess 2.

Why the other options are wrong

  • A. The file is written and read successfully because both classes are serializable, so read error is never printed.
  • B. players is a non-transient instance field, so it is serialized and restored as 2, not 0.
  • C. Deserialization does not call the Software or Game constructors, so Software Game is printed only once.
  • E. Game is serializable through Software, so writeObject succeeds and write error is never printed.
  • F. The constructors run only once, and players is restored as 2, so neither part of this output matches.

Question 7

Which two statements are true about modules in the Java Platform Module System? (Choose two.)

  1. The module-info.java has to be located in the Java bin directory.
  2. They are a group of related Java packages and resources such as XML files, images, and properties file.
  3. The classes in a module are loaded using class-path.
  4. They support versioning of Java modules.
  5. Packages within the module are hidden by default.
Show answer and explanation

Correct answer: B, E. They are a group of related Java packages and resources such as XML files, images, and properties file; Packages within the module are hidden by default.

A module in the Java Platform Module System is a named, self-describing group of related packages together with resources such as XML files, images and properties files, described by a module-info.java file at the root of the module's source tree. Strong encapsulation is a core feature: every package in a module is hidden from other modules by default, and only packages explicitly listed in an exports (or opens) directive are accessible from outside. These two facts make the statements about grouping packages and resources and about packages being hidden by default true.

Why the other options are wrong

  • A. module-info.java is placed at the root of the module's source directory, not in the Java bin directory.
  • C. Classes in a module are loaded from the module path, not the class path, which only feeds the unnamed module.
  • D. The module system can only record an optional version string in a module descriptor; it does not support selecting between versions of a module, and resolving versions is left to build tools.

Question 8

Assuming that the data.txt file exists and has the following content:

text1
text2
text3

Given the code fragment:

try {
    Path p = new File("data.txt").toPath();
    Stream<String> lines = Files.lines(p);
    String data = lines.collect(Collectors.joining("-"));
    System.out.println(data);
    String data2 = Files.readAllLines(p).get(3);
    System.out.println(data2);
} catch (IOException ex) {
    System.out.println(ex);
}

What is the result?

  1. text1text2text3text3
  2. text1-text2-text3 A java.lang.IndexOutOfBoundsException is thrown.
  3. text1-text2-text3 text1 text2 text3
  4. text1-text2-text3 text3
Show answer and explanation

Correct answer: B. text1-text2-text3 A java.lang.IndexOutOfBoundsException is thrown.

Files.lines returns a Stream<String> of the three lines, and Collectors.joining("-") joins them with hyphens, so the code prints text1-text2-text3. Files.readAllLines then returns a List holding text1, text2 and text3 at indexes 0, 1 and 2. The call get(3) asks for a fourth element, so it throws an IndexOutOfBoundsException before data2 is printed. That exception is unchecked and is not a subclass of IOException, so the catch block does not handle it, and it propagates out of the code after the first line has already been printed.

Why the other options are wrong

  • A. Collectors.joining("-") puts a hyphen between the lines, and get(3) throws instead of returning text3.
  • C. get(3) returns a single element, not the whole list, and index 3 is past the end of a three-element list, so it throws an IndexOutOfBoundsException.
  • D. The last line is at index 2, so get(3) throws an IndexOutOfBoundsException and text3 is never printed.

Question 9

Given the code fragment:

ExecutorService executorService = Executors.newSingleThreadExecutor();
Set<Callable<String>> workers = new HashSet<Callable<String>>();
workers.add(new Callable<String>() {
    public String call() throws Exception {
        return "1";
    }
});
workers.add(new Callable<String>() {
    public String call() throws Exception {
        return "2";
    }
});
workers.add(new Callable<String>() {
    public String call() throws Exception {
        return "3";
    }
});

Which code fragment invokes all callable objects in the workers set?

  1. for (int i=0; i<3;i++) { String result = executorService.invokeAny(cThreads); System.out.println(result); }
  2. executorService.submit(cThreads);
  3. List<Future<String>> futures = executorService.invokeAny(workers); for (Future<String> future : futures) { System.out.println(future.get()); }
  4. List<Future<String>> futures = executorService.invokeAll(workers); for (Future<String> future : futures) { System.out.println(future.get()); }
Show answer and explanation

Correct answer: D. List<Future<String>> futures = executorService.invokeAll(workers); for (Future<String> future : futures) { System.out.println(future.get()); }

ExecutorService.invokeAll takes a Collection of Callable tasks, runs every one of them, and returns a List<Future<T>> holding one completed Future per task. Passing the workers set to invokeAll therefore executes all three callables on the single-thread executor, and the loop calls future.get() on each Future to print the values 1, 2 and 3 (in the iteration order of the HashSet). Because every task has already finished when invokeAll returns, get() never blocks. The statement compiles because the declared type List<Future<String>> matches the return type of invokeAll for a Set<Callable<String>>.

Why the other options are wrong

  • A. cThreads is never declared, and invokeAny runs only until one task succeeds and returns that single result, so it never invokes all callables.
  • B. cThreads is not declared, and submit accepts a single Callable or Runnable, not a collection of tasks.
  • C. invokeAny returns a single String result, so assigning it to List<Future<String>> fails to compile.

Question 10

Which statement is true?

  1. The lock() method returns a boolean indicator immediately regardless if it has or has not managed to acquire the lock.
  2. The lock() method returns a boolean indicator immediately if it has managed to acquire the lock, otherwise it waits for the lock acquisition.
  3. The tryLock() method returns a boolean indicator immediately if it has managed to acquire the lock, otherwise it waits for the lock acquisition.
  4. The tryLock() method returns a boolean indicator immediately regardless if it has or has not managed to acquire the lock.
Show answer and explanation

Correct answer: D. The tryLock() method returns a boolean indicator immediately regardless if it has or has not managed to acquire the lock.

Lock.tryLock() acquires the lock only if it is free at the moment of the call, and it returns at once in both cases: true when it acquired the lock and false when it did not. It never waits. Lock.lock() is declared void, so it returns no boolean at all; if another thread holds the lock, the calling thread blocks until it can acquire it. The only statement that matches this behavior is the one saying tryLock() returns a boolean immediately whether or not it acquired the lock.

Why the other options are wrong

  • A. lock() returns void, not a boolean, and it blocks until the lock is acquired instead of returning immediately.
  • B. lock() returns void, so it never returns a boolean indicator; it simply blocks until it holds the lock.
  • C. tryLock() never waits: if the lock is unavailable it returns false at once (only the overload tryLock(long, TimeUnit) waits).

What people say about the full 1Z0-829 pack 5.0 from 6

I've been scammed by other websites before but Cert Stash has proven to be trustworthy. I got updated dumps and passed the 1Z0-829 test on my first try. Huge thanks..!
Bobby M1Z0-829
Yesterday, I passed my exam 1Z0-829 JAVA SE 17. TBH, Wasn't easy to prepare but thanks to Cert Stash study material that helped to prepare for my exam efficiently.
Michael Osborne1Z0-829
Got the job done for 1Z0-829.
Nadia Robin1Z0-829

Question 11

Which statement is true about migration?

  1. Every module is moved to the module path in a bottom-up migration.
  2. Every module is moved to the module path in a top-down migration.
  3. Unnamed modules are automatic modules in a top-down migration.
  4. The required modules migrate before the modules that depend on them in a top-down migration.
Show answer and explanation

Correct answer: B. Every module is moved to the module path in a top-down migration.

In a top-down migration you start with the application code at the top of the dependency graph. The components whose source you control are converted into explicit modules, and they are placed on the module path together with the remaining JAR files, unchanged. Those unconverted JARs become automatic modules, which are named modules that the explicit modules can require. Because every JAR, converted or not, ends up on the module path, every module is moved to the module path in a top-down migration. The libraries are converted into explicit modules later, as their maintainers modularize them.

Why the other options are wrong

  • A. A bottom-up migration converts the lowest-level JAR first and places only that one on the module path, leaving the rest on the class path in the unnamed module.
  • C. In a top-down migration the unconverted JARs go on the module path as automatic modules, which are named modules; the unnamed module holds only what remains on the class path.
  • D. Migrating required modules before the modules that depend on them describes a bottom-up migration, whereas a top-down migration starts with the application at the top.

That was 11 of 130.

The full Oracle 1Z0-829 pack has all 130 questions, each with the answer, the explanation and why the other options are wrong, plus a questions-only copy for timed runs. US$39, paid once, with free monthly updates and a pass-or-your-money-back guarantee.

Get the full pack

Not ready yet? Get the first 36 free as one PDF by email. Get the Half Pack →