Virtual Threads (JEP 425) are designed for high-throughput concurrent applications, especially those with many tasks that spend time waiting (like I/O). They allow easy-to-write synchronous code to scale to a massive number of concurrent tasks without the overhead of platform threads, making them ideal for responsive services handling many data streams. While CompletableFuture and Reactive Streams are also for asynchronous processing, Virtual Threads offer a simpler, more scalable model for this scenario.

A `switch` expression must be exhaustive. This means for an enum input, either all possible enum constants must be covered explicitly by case labels, or a `default` case must be present. This is a key difference from `switch` statements, which do not require exhaustiveness. The other options are incorrect: a `default` case is not needed if all values are covered, `break` is not used in expression form (we use `->` or `yield`), and while a block is often used, it’s not a syntactical requirement for the entire expression itself.

The core rule of sealed classes is that all permitted subclasses must be declared in the `permits` clause of the sealed type. Therefore, to add a new subclass (`PushNotification`), you must first edit the source code of the sealed parent (`Notification`) to add the new class name to its `permits` list. Only then can you declare the new class itself. The hierarchy is a compile-time construct, and the compiler will reject any subclass not explicitly permitted.

The resource bundle search order is specific-to-general. For a requested locale `fr_CA`, the JVM looks for: 1) An exact match: `basename_fr_CA`. 2) A language match for the parent locale: `basename_fr`. 3) The default bundle: `basename`. It does not look for country-specific bundles without the language (`_CA`) as an intermediate step.

The `synchronized` modifier ensures atomicity (the method runs completely without interference from other threads on the same instance) and visibility (changes to shared data are flushed to main memory, making them visible to other threads). Using just `synchronized` on an instance method is sufficient for this scenario if the critical section is the method itself. `static synchronized` would lock on the class, which is overkill if the data is instance-specific. `final` does not provide synchronization or visibility guarantees. Relying solely on the database transaction does not address Java-level memory visibility of any state read or written before/after the call.

`List.removeIf(Predicate)` is the modern, safe, and efficient way to remove elements from a collection based on a condition. It is designed specifically for this purpose and handles the underlying iterator logic safely, avoiding `ConcurrentModificationException`. Option A creates a new list but does not modify the original. Option C will throw a `ConcurrentModificationException` because it modifies the list while iterating with a for-each loop. Option D is functionally correct but is more verbose and lower-level than the dedicated `removeIf` method.

The `accumulateAndGet(int x, IntBinaryOperator accumulatorFunction)` method atomically updates the current value with the results of applying the given function. The function is applied with the *current* value as the first argument (`a`) and the provided value (`5`) as the second argument (`b`). Here, the current value is 0. The lambda `(a, b) -> a * b` calculates `0 * 5`, which is 0. Therefore, the `AtomicInteger` is set to 0 and 0 is returned.

The fundamental unit of accessibility between modules is the package. If a class should be hidden from other modules, it must reside in a package that is not exported in `module-info.java`. The correct approach is to refactor the code, placing public API in an exported package (e.g., `com.app.utils.api`) and internal classes like `InternalCache` in a non-exported package (e.g., `com.app.utils.internal`). A `public sealed` class is still accessible if its package is exported. A `private` top-level class is not allowed. `requires transitive` affects readability, not hiding.

Due to type erasure, the runtime does not know the concrete type of `T`. Therefore: A) `new T[10]` is a compile-time error. B) `catch (T e)` is a compile-time error because `T` is not a concrete Throwable type. C) `item instanceof T` is a compile-time error for the same reason. D) Casting to `T` is allowed (`(T) someObject`), but it is an unchecked cast. The compiler will insert a checkcast instruction, but a `ClassCastException` may be thrown at runtime if `someObject` is not compatible with the actual type argument used for `T`. This is the only operation listed that is syntactically valid.

Virtual Threads (JEP 425) are designed for high-throughput concurrent applications, especially those with many tasks that spend time waiting (like I/O). They allow easy-to-write synchronous code to scale to a massive number of concurrent tasks without the overhead of platform threads, making them ideal for responsive services handling many data streams. While CompletableFuture and Reactive Streams are also for asynchronous processing, Virtual Threads offer a simpler, more scalable model for this scenario.0