Hard Difficulty Questions

Ensure each thread has its own copy of the file handle

Why wrong: Thread safety does not prevent resource leaks.

Call close() on each stream in a separate try-catch block

Why wrong: This is error-prone and can lead to leaks if an exception occurs before close.

Use FileLock to prevent concurrent access

Why wrong: FileLock prevents conflicts but does not handle resource cleanup.

A lambda expression can throw any checked exception.

Why wrong: False: Lambdas can only throw checked exceptions declared in the functional interface method, not any checked exception.

A lambda expression can be used to implement multiple abstract methods.

Why wrong: False: A lambda can only implement one abstract method, not multiple.

A lambda expression can be used to create an instance of an abstract class.

Why wrong: False: Lambdas cannot create instances of abstract classes; they work only with functional interfaces.

Optional.of(null) returns an empty Optional

Why wrong: Optional.of(null) throws NullPointerException; use ofNullable for null-safe.

Optional.get() on empty Optional returns null

Why wrong: get() throws NoSuchElementException if Optional is empty.

2

Why wrong: Fall-through occurs to case 3.

2 3 4

Why wrong: Break in case 3 prevents fall-through to case 4.

default 1 2 3

Why wrong: Default only runs if no match; here case 2 matches.

Arrays.asList("A","B","C")

Why wrong: Incorrect: this returns a fixed-size but mutable list.

new ArrayList<>(List.of("A","B","C"))

Why wrong: Incorrect: this creates a mutable list.

Collections.unmodifiableList(new ArrayList<>(List.of("A","B","C")))

Why wrong: Incorrect: while the wrapper prevents direct modification, the backing list can still be changed via other references, so it is not immutable.

None of the above

Why wrong: Incorrect: List.of works.

Compilation fails

Why wrong: The code compiles successfully.

{x=30, y=20}

Why wrong: Incorrect: computeIfAbsent does not replace existing values.

{x=30, y=20, z=40}

Why wrong: Incorrect: neither key is modified.

{x=10, y=20, z=40}

Why wrong: Incorrect: computeIfPresent does not add absent keys.

A while loop always executes at least once.

Why wrong: While loop may execute zero times.

A do-while loop may execute zero times if the condition is false.

Why wrong: Do-while executes at least once.

The services module is using an automatic module, which automatically reads the unnamed module, while the web module is a named module that does not.

Why wrong: Even if the services module were automatic, the web module being named still cannot access the class path package if it is split.

The class path is not scanned for JAR files unless the module path is empty.

Why wrong: The class path is always scanned for classes, but named modules cannot access classes from the class path if the package is split.

The core module's module-info.java does not export the package to the web module; it only exports it to all modules.

Why wrong: The export to all modules should allow the web module to access it, but the issue is the split package, not the export.

0-0 0-1 0-2 1-0 2-0 2-1 2-2

Why wrong: Incorrect: This option includes the pair (1,0) which is skipped by the 'continue outer' statement when i=1.

0-0 0-1 0-2 1-0 1-1 1-2 2-0 2-1 2-2

Why wrong: Incorrect: This option includes all pairs for i=1, but the 'continue outer' prevents any output from the i=1 iteration.

0-0 0-1 0-2 2-0 2-1

Why wrong: Incorrect: Although this option text is identical to D, the intended correct answer is D. The duplication is a flaw in the question design.

A sealed interface cannot use the permits clause.

Why wrong: This statement is false because a sealed interface can indeed use the `permits` clause to specify which classes can implement it.

The permits clause must list all direct subclasses of a sealed class.

Why wrong: This statement is false. The `permits` clause is not mandatory if the sealed class and its direct subclasses are declared in the same compilation unit. Additionally, even when used, it must list all permitted subclasses, but it is not always required.

A sealed class must be declared as abstract.

Why wrong: This statement is false. A sealed class can be concrete (non-abstract). For example, a sealed class can be instantiated.

Duration.ofDays(1) returns a Duration that is daylight-saving-safe.

Why wrong: Duration is fixed 24 hours, not DST-aware.

Duration.between(LocalDate.now(), LocalDate.now().plusDays(1)) returns a Duration of 1 day.

Why wrong: Duration.between requires temporals that support seconds; LocalDate does not.

Duration can represent a period of months.

Why wrong: Period represents months, not Duration.

Define custom exceptions without providing any additional context.

Why wrong: Custom exceptions should include useful information.

Catch exceptions at the highest level of the application and log them generically.

Why wrong: Catching Exception broadly is discouraged; handle where possible.

Throws DateTimeException

Why wrong: Incorrect: ZonedDateTime.of does not throw an exception; it adjusts the time.

2024-03-10T02:30-05:00[America/New_York]

Why wrong: Incorrect: This represents EST, but at 2:30 AM the time does not exist; Java automatically adjusts.

2024-03-10T02:30-04:00[America/New_York]

Why wrong: Incorrect: The offset -04:00 indicates EDT, but the time 2:30 does not exist on that date; Java does not preserve the time with the EDT offset.

Files.copy(source, target, StandardCopyOption.REPLACE_EXISTING)

Why wrong: Files.copy is efficient but may not be as performant as direct channel transfer for very large files.

Using Files.readAllBytes() then Files.write()

Why wrong: ReadAllBytes loads the entire file into memory, which is not feasible for a 2 GB file.

Using FileInputStream and FileOutputStream with a buffer of 8192 bytes

Why wrong: Traditional stream copying with a small buffer is inefficient for large files.

Deserialization succeeds only if the new field is marked transient.

Why wrong: Transient fields are not serialized, but the new field will be default even if not transient.

Deserialization throws StreamCorruptedException due to missing field.

Why wrong: StreamCorruptedException indicates corruption, not compatibility issues.

Deserialization throws InvalidClassException because the class definition has changed.

Why wrong: InvalidClassException occurs only if serialVersionUID mismatches, which it does not here.

Runtime exception because Inner class is not static.

Why wrong: Inner class instantiation is correct.

Compilation error because x is private.

Why wrong: Inner classes can access private fields of the enclosing class.

Prints 0 because x is not initialized in Inner.

Why wrong: x is accessed from Outer instance.

Change line 4 to: for (int i = 1; i <= arr.length; i++)

Why wrong: Starts at 1, misses arr[0] and still out of bounds at i=3.

Change line 4 to: for (int i = 0; i <= arr.length-1; i++)

Why wrong: Changing the loop condition to `i <= arr.length-1` does not fix the exception because it still iterates up to the last valid index; the original exception likely arose from accessing an index beyond the array's bounds, and this alteration merely rewrites the same boundary check without altering the loop's range. It is tempting because `<=` with `arr.length-1` is a common idiom for inclusive upper bounds, and would be correct if the loop needed to access every element including the last, but the scenario requires a different iteration pattern—such as stopping one element earlier—which this change does not achieve.

Change line 5 to: System.out.println(arr[i-1]);

Why wrong: Would print wrong elements and still go out of bounds for i=3? Actually i<=3, i=3: arr[2] okay, but i=3 still accesses arr[2]? No, i=3 arr[2] works but loop still goes to i=3? Wait line 4 condition i<=arr.length, with arr.length=3, i runs 0,1,2,3. i=3: arr[3] out of bounds. Changing to arr[i-1] would cause i=0 arr[-1] exception earlier. So not valid.

Use .stream().parallel() with a custom thread pool and ensure the stream source is not modified during operation.

Why wrong: Ensuring no modification is difficult in a real-time system; this approach does not address the root cause of concurrent access efficiently.

Replace ArrayList with CopyOnWriteArrayList and use .parallelStream() with the same collector.

Why wrong: CopyOnWriteArrayList is inefficient for frequent writes; also, groupingBy is not concurrent and may not perform optimally.

Replace the collector with Collectors.groupingByConcurrent() and use .parallelStream() directly on the original list.

Why wrong: Although groupingByConcurrent is thread-safe, the source list may be modified during iteration, leading to undefined behavior.

Wrap the parse call in a synchronized block

Why wrong: Thread-safe but causes contention, reducing performance.

Use a ThreadLocal<SimpleDateFormat> to give each thread its own instance

Why wrong: A ThreadLocal<SimpleDateFormat> eliminates shared mutable state between threads, which would fix the thread-safety issue if the requirement were to continue using SimpleDateFormat. However, the stem specifies parsing into an Instant, and SimpleDateFormat cannot produce an Instant directly—it produces a java.util.Date, which lacks nanosecond precision and the UTC context that Instant requires. The correct fix is to switch to java.time.format.DateTimeFormatter with a pattern like "yyyy-MM-dd'T'HH:mm:ss.SSSX" and call parse(CharSequence, Instant::from), which is inherently thread-safe and yields an Instant. This option is tempting because ThreadLocal is a standard workaround for non-thread-safe SimpleDateFormat in legacy code, and it would work if the target type were Date rather than Instant.

Create a new SimpleDateFormat instance for each parse call

Why wrong: Avoids thread safety but creates many objects, hurting performance.