[NEW] Oracle Certified Professional Java SE 11 Developer

Detailed Exam Domain CoverageCore Java Language Features (25%)Topics: Primitive data types, literals, and operators; Control flow statements and exception handling; Classes, interfaces, enums, and records; Java SE 11 language enhancements and preview features. Object-Oriented Programming and Design (25%)Topics: Encapsulation, inheritance, and polymorphism; Design principles (SOLID) and common design patterns; Access modifiers, inner classes, and nesting; Composition vs. inheritance decisions.

Functional Programming and Streams (25%)Topics: Lambda expressions and method references; Functional interfaces and default methods; Stream pipeline operations (filter, map, reduce, collect); Optional API and handling nulls. Concurrency, JVM Internals, and Performance (25%)Topics: Thread lifecycle, Runnable, Callable, and executors; Synchronization, locks, and concurrent collections; Garbage collection algorithms and tuning; Class loading, module system, and JVM options. Earning your Oracle Certified Professional (OCP) Java SE 11 Developer credential is one of the most definitive ways to prove your backend engineering expertise.

However, passing this exam requires more than just a general understanding of syntax. The actual exam is notorious for testing obscure edge cases, unexpected compiler behavior, and intricate API details that developers rarely think about during daily coding. I designed this practice test question bank to bridge the gap between knowing Java and passing the OCP exam.

Instead of giving you simple definitions, these questions mirror the actual test environment's complexity. You will learn to spot the subtle traps built into questions about local variable type inference, stream execution order, and multi-threaded race conditions. Every question in this set includes a comprehensive breakdown, ensuring you understand exactly why the correct choice stands and why the other options fail.

Practice Questions PreviewQuestion 1: Core Java Language FeaturesWhat is the result of attempting to compile and run the following code snippet? Javapublic class LambdaVar { public static void main(String[] args) { java. util.

function. BinaryOperator<String> bo = (var s1, String s2) -> s1 + s2; // Line 1 var dynamicList = new java. util.

ArrayList<>(); // Line 2 dynamicList. add(10); var item = dynamicList. get(0); // Line 3 System.

out. println(item. getClass().

getName()); }}A) Compiles fine and prints java. lang. Integer.

B) Line 1 causes a compilation error because var cannot be mixed with explicit types in lambda parameters. C) Line 2 causes a compilation error because the diamond operator cannot be used with var without an explicit type context. D) Line 3 causes a compilation error because dynamicList defaults to an ArrayList of Object types and cannot resolve getClass().

E) Line 1 and Line 2 both cause compilation errors. F) The code compiles successfully but throws a ClassCastException at runtime. Answers & Explanations:Correct Answer: BOption Breakdown:Why B is correct: Java 11 allows the use of var in lambda parameters, but it enforces a strict consistency rule.

You must either use var for all parameters, use explicit types for all parameters, or use implicit types for all parameters. Mixing (var s1, String s2) is illegal and triggers a compilation error. Why A is incorrect: The code will never run to print anything because Line 1 breaks compilation rules.

Why C is incorrect: Line 2 is perfectly valid. When var is combined with the empty diamond operator <>, Java infers the type as an ArrayList of Object. Why D is incorrect: Line 3 compiles without issue.

Since dynamicList is an ArrayList<Object>, get(0) returns an Object reference. The getClass() method is defined directly in the Object class, so it is fully accessible. Why E is incorrect: Only Line 1 causes a compilation failure; Line 2 is legally valid syntax.

Why F is incorrect: The code fails during compilation, meaning no runtime exceptions can occur. Question 2: Functional Programming and StreamsConsider the following application code. What will be displayed in the console when this code executes?

Javaimport java. util. List;import java.

util. Optional;public class StreamQuery { public static void main(String[] args) { List<String> data = List. of("apple", "banana", "apricot", "cherry"); Optional<String> result = data.

stream() . filter(s -> s. startsWith("a")) .

map(s -> { System. out. print(s + " "); return s.

toUpperCase(); }) . sorted() . findFirst(); }}A) apple apricotB) appleC) Nothing will be printed because the stream pipeline is lazy and findFirst() does not trigger intermediate operations.

D) apple apricot banana cherryE) A compilation error occurs because sorted() cannot be called immediately after a mapping operation that yields strings. F) A NullPointerException is thrown at runtime because List. of elements are checked sequentially.

Answers & Explanations:Correct Answer: AOption Breakdown:Why A is correct: Streams are generally lazy, but certain intermediate operations like sorted() act as a barrier. To sort the elements, the stream must evaluate all matching upstream elements first. The filter passes "apple" and "apricot" down to the map phase, which prints both strings before the sorted() operation can organize them and hand the first one off to findFirst().

Why B is incorrect: If sorted() were absent, short-circuiting logic in findFirst() would process only "apple". However, the sorting barrier forces evaluation of both valid matching elements. Why C is incorrect: findFirst() is a terminal operation, meaning it actively executes the stream pipeline.

Why D is incorrect: Elements like "banana" and "cherry" are discarded early by the filter stage, so they never enter the map block to be printed. Why E is incorrect: The map operation safely yields a Stream<String>. String implements Comparable, making it perfectly eligible for the no-argument sorted() method.

Why F is incorrect: List. of creates a structurally valid, non-null collection, and no element processing triggers a null pointer. Question 3: Concurrency, JVM Internals, and PerformanceWhat is the behavior of the following multi-threaded program?

Javaimport java. util. concurrent.

*;public class ConcurrencyTest { public static void main(String[] args) throws Exception { ExecutorService service = Executors. newFixedThreadPool(2); Future<String> f1 = service. submit(() -> "Task 1"); Future<?

> f2 = service. submit(() -> { System. out.

print("Task 2 "); }); System. out. print(f1.

get() + " "); System. out. print(f2.

get() + " "); service. shutdown(); }}A) Prints Task 2 Task 1 null (or Task 1 Task 2 null depending on thread scheduling). B) Causes a compilation error because submit() cannot accept a lambda expression without an explicit functional interface cast.

C) Prints Task 1 Task 2 followed by a runtime NullPointerException at f2. get(). D) The code compiles successfully but hangs indefinitely because service.

shutdown() is called too late. E) Causes a compilation error because Future<? > cannot capture the return value of a Runnable lambda expression.

F) Prints Task 1 and then throws an InterruptedException. Answers & Explanations:Correct Answer: AOption Breakdown:Why A is correct: The first task targets Callable<String> and returns "Task 1". The second task matches Runnable because it has a void return shape.

When you call get() on a Future backed by a Runnable, it blocks until execution completes and then returns null. Depending on how threads are prioritized, "Task 2 " may output before or after the main thread prints the results of the get() calls. Why B is incorrect: The compiler matches the functional expressions cleanly to overloaded versions of submit(Callable) and submit(Runnable).

Why C is incorrect: Calling get() on a completed Runnable task cleanly returns null as a value; it does not throw an exception. Why D is incorrect: The code terminates normally. The get() methods block until tasks finish, ensuring shutdown() is safely called right after.

Why E is incorrect: Future<? > uses a wildcard pattern, which safely accommodates the null-returning result of a Runnable sequence. Why F is incorrect: No execution loops are disrupted or interrupted, meaning no InterruptedException will be thrown.

Welcome to the Mock Exam Practice Tests Academy to help you prepare for your Oracle Certified Professional: Java SE 11 Developer Practice Tests. You can retake the exams as many times as you wantThis is a huge original question bankYou get support from instructors if you have questionsEach question has a detailed explanationMobile-compatible with the Udemy appI hope that by now you're convinced! And there are a lot more questions inside the course.