Programming Concepts using Java · Quiz 2 · Jan 2025

In `main()`, `findMax` is called with two different argument types: `Set<Integer> s` and `Set<Double> s1`. **1. Why Generics or Upper-Bounded Wildcards are Needed:** Both `Integer` and `Double` are subclasses of `Number`. In Java, generics are **invariant** (`Set<Integer>` is not a subtype of `Set<Number>`), so the method parameter must use either a generic type parameter `<T extends Number>` or an upper-bounded wildcard `Set<? extends Number>`: - **Option B (`public static <T extends Number> void findMax(Set<T> s)`)**: Declares the generic type parameter `<T extends Number>` before the return type `void`. Calling `findMax(s)` infers `T = Integer`, and `findMax(s1)` infers `T = Double`. (**Valid**) - **Option C (`public static void findMax(Set<? extends Number> s)`)**: Uses an upper-bounded wildcard `? extends Number`, which accepts a `Set` of any subtype of `Number` (`Set<Integer>` or `Set<Double>`). (**Valid**) **2. Why Options A and D Fail:** - **Option A**: Uses `Set<T>` without declaring `<T>` before the return type `void`, causing a compiler error (`cannot find symbol T`). - **Option D**: Only accepts `Set<Double>`, so `findMax(s)` (where `s` is `Set<Integer>`) causes a compilation error. **Answer: Options B and C.** A: **Incorrect:** Fails to declare the type parameter `<T>` before the return type `void`, resulting in a compilation error. B: **Correct:** Properly declares `<T extends Number>` as a generic method type parameter, accepting both `Set<Integer>` and `Set<Double>`. C: **Correct:** Uses an upper-bounded wildcard `Set<? extends Number>`, which accepts `Set<Integer>` and `Set<Double>`. D: **Incorrect:** `Set<Double>` cannot accept `Set<Integer> s` because generic types in Java are invariant.

Let us trace the reference type of `o1` and the method calls in `main`: **1. Reference Type vs Object Type:** `Deliverable o1 = new FoodOrder();` Here, the compile-time reference type of `o1` is `Deliverable`. **2. Checking `o1.track()`:** - In Java, the compiler checks method calls against the **compile-time reference type** (`Deliverable`). - The `Deliverable` interface only declares `status()` and `deliver()`. It does **not** declare `track()` (which belongs to `Trackable`). - Therefore, `o1.track();` fails to compile with the error: `cannot find symbol: method track() in interface Deliverable`. **Answer: This program generates compiler error because o1 of type Deliverable cannot invoke method track().** A: **Incorrect:** The code does not compile because `o1` is declared of type `Deliverable`, which does not have a `track()` method. B: **Incorrect:** The code fails at compile time on `o1.track()`. C: **Correct:** Because `o1` has compile-time type `Deliverable`, calling `o1.track()` causes a compilation error since `track()` is only defined in `Trackable`. D: **Incorrect:** In Java 8+, `static` methods in interfaces (`Deliverable.status()` and `Trackable.status()`) *must* be invoked using the interface name, so LINE-1 and LINE-2 are completely valid.

Let us trace how `categorizePatients` populates `rPatients` and `oPatients`: **1. Condition in `check(int visits)`:** `check(visits)` returns `true` if `visits > 3` (strictly greater than 3). If `true`, the patient name is added to `rPatients`; otherwise (`visits <= 3`), it is added to `oPatients`. - `"James": 5` \( \rightarrow 5 > 3 \rightarrow \) `rPatients` - `"Ram": 2` \( \rightarrow 2 \le 3 \rightarrow \) `oPatients` - `"Aisha": 4` \( \rightarrow 4 > 3 \rightarrow \) `rPatients` - `"Tanya": 1` \( \rightarrow 1 \le 3 \rightarrow \) `oPatients` - `"Iva": 3` \( \rightarrow 3 \le 3 \rightarrow \) `oPatients` **2. Sorting by `TreeSet<String>`:** Both `rPatients` and `oPatients` are `TreeSet<String>` instances, which automatically store elements in **natural alphabetical (lexicographical) order**: - `rPatients`: `[Aisha, James]` - `oPatients`: `[Iva, Ram, Tanya]` **Answer: R Patients: [Aisha, James] and O Patients: [Iva, Ram, Tanya] (Option C).** A: **Incorrect:** Swaps the regular and occasional patients and does not sort them alphabetically as `TreeSet` does. B: **Incorrect:** `Iva` has `3` visits, and since `3 > 3` is `false`, `Iva` belongs to `oPatients`, not `rPatients`. C: **Correct:** Patients with `visits > 3` (`Aisha`, `James`) go into `rPatients` and those with `visits <= 3` (`Iva`, `Ram`, `Tanya`) go into `oPatients`, both sorted alphabetically by `TreeSet`. D: **Incorrect:** `TreeSet` guarantees that elements are stored and printed in natural sorted order.

Let us trace the cloning and field modification in `main`: **1. Creating `car1` and Cloning `car2`:** - `Car car1 = new Car(25);` creates a `Car` object with `car1.mileage = 25`. - `Car` implements `Cloneable` and overrides `clone()` using `super.clone()`. - `Car car2 = car1.clone();` creates a **new, distinct `Car` object** on the heap and copies the primitive field `mileage = 25` into `car2`. **2. Modifying `car1.mileage`:** - `car1.mileage = 30;` changes `car1`'s `mileage` to `30`. - Because `car2` is a separate cloned object with its own `int mileage` field, `car2.mileage` remains `25`. **3. Output:** `car1.getMileage() + car2.getMileage()` computes `30 + 25 = 55`. **Answer: 55.** A: **Correct:** `car1.getMileage()` is `30` and `car2.getMileage()` remains `25`, so `30 + 25 = 55` is printed. B: **Incorrect:** `car1.mileage` was updated from `25` to `30`, so the sum is `30 + 25 = 55`, not `25 + 25 = 50`. C: **Incorrect:** `car2` is a separate cloned instance, so changing `car1.mileage` to `30` does not change `car2.mileage` to `30`. D: **Incorrect:** `Car` implements `Cloneable`, so `super.clone()` succeeds without throwing `CloneNotSupportedException`.

Let us examine how to safely remove an element from a `List` while iterating over it with a `ListIterator`: **1. Target Output:** The initial list has `Tagore (12)`, `Sudha (3)`, `Amitabh (7)`, `Sharukh (5)`. The condition `if (a.experience < 5)` matches `Sudha (3)`, which must be removed so that the output is `[Tagore, Amitabh, Sharukh]`. **2. Using `ListIterator.remove()`:** - Inside the loop `while (it.hasNext()) { Artist a = it.next(); ... }`, calling `it.remove()` (with **no arguments**) removes the last element returned by `it.next()` from the underlying list. - Calling `artistList.remove(a)` directly while iterating would throw a `ConcurrentModificationException` (and note the parameter is named `artistList`, not `aList`). - `Iterator.remove()` takes no parameters, so `it.remove(a)` does not compile. **Answer: it.remove().** A: **Incorrect:** `ListIterator.remove()` does not take any arguments; `it.remove(a)` causes a compilation error. B: **Incorrect:** The list parameter is named `artistList` (not `aList`), and `List.remove()` requires an index or object argument. C: **Correct:** `it.remove()` safely removes the current element returned by `it.next()` (`Sudha`) without throwing `ConcurrentModificationException`. D: **Incorrect:** `aList` is not defined (the parameter is `artistList`), and modifying the list directly during iteration throws `ConcurrentModificationException`.

Let us trace the execution and exception propagation step by step: **1. First Call in `processSalaries()`:** - `calSalary(50000, 10000)` is called. - Since `bonus = 10000` is not `< 0`, it prints: `Total Salary: 60000` **2. Second Call in `processSalaries()`:** - `calSalary(60000, -5000)` is called. - Since `bonus = -5000 < 0`, it throws `new Exception("Invalid bonus")`. - The `catch (Exception e)` block in `processSalaries()` catches this exception, prints: `Caught in processSalaries` and then re-throws the exception via `throw e;`. **3. Catching the Re-thrown Exception in `main()`:** - The re-thrown exception propagates to `main()`, where `catch (Exception e)` catches it and prints: `Caught in main` **Answer: Total Salary: 60000, Caught in processSalaries, Caught in main (Option C).** A: **Incorrect:** Omits `Total Salary: 60000`, which is printed by the first call `calSalary(50000, 10000)` before the exception occurs. B: **Incorrect:** The re-thrown exception is caught by the `try-catch` block in `main()`, so the program terminates normally. C: **Correct:** `calSalary(50000, 10000)` prints `Total Salary: 60000`, then `calSalary(60000, -5000)` throws an exception caught in `processSalaries` (printing `Caught in processSalaries`) and re-thrown to `main` (printing `Caught in main`). D: **Incorrect:** The exception is caught in `processSalaries` first before being re-thrown to `main`.

Let us trace the execution of `main` in `Test`: **1. First Call (`u1.register()`):** - `u1` has `email = "anu.kuriyan@ex.com"`. - `email.contains("@")` is `true`, so no exception is thrown and it prints: `Registration successful` **2. Second Call (`u2.register()`):** - `u2` has `email = "narendran.pk"`. - `!email.contains("@")` is `true`, so `register()` throws `new RegException("Registration failed: Invalid email format")`. **3. Catch Block in `main`:** - `catch (RegException e)` catches the exception and executes `System.out.println("Error: " + e.getMessage());`. - Since `RegException` passes `message` to `super(message)`, `e.getMessage()` returns `"Registration failed: Invalid email format"`. - Thus, it prints: `Error: Registration failed: Invalid email format`. **Answer: Registration successful followed by Error: Registration failed: Invalid email format (Option A).** A: **Correct:** `u1.register()` prints `Registration successful`, and `u2.register()` throws `RegException`, which is caught to print `Error: Registration failed: Invalid email format`. B: **Incorrect:** `e.getMessage()` returns the message string passed to the constructor, not the class name `RegException`, and it is prefixed with `"Error: "`. C: **Incorrect:** The `println` statement in `catch` prepends `"Error: "` to `e.getMessage()`. D: **Incorrect:** `u1.register()` succeeds and prints `Registration successful` before `u2.register()` throws the exception.

Let us check the access modifiers of each method in `pack1.A` when accessed from subclass `pack2.B` (in a **different package**): - **`void AMethod()` (LINE 1 — default / package-private access):** A method with no access modifier has **package-private** visibility. It is accessible *only* within the same package (`pack1`). Even a subclass (`B`) in a different package (`pack2`) cannot access it! Thus, **LINE 1 generates a compilation error**. - **`private void BMethod()` (LINE 2 — `private` access):** `private` methods are accessible *only* within the declaring class `A`. Thus, **LINE 2 generates a compilation error**. - **`protected void CMethod()` (LINE 3 — `protected` access):** `protected` methods are accessible within subclasses even in different packages (`pack2.B extends pack1.A`). Thus, LINE 3 is **valid**. - **`public void DMethod()` (LINE 4 — `public` access):** `public` methods are accessible everywhere. Thus, LINE 4 is **valid**. **Answer: LINE 1 and LINE 2 generate compilation errors.** A: **Incorrect:** `AMethod()` has package-private (default) access, so calling `super.AMethod()` from a different package (`pack2`) also fails to compile on LINE 1. B: **Incorrect:** `CMethod()` is `protected`, which is accessible to subclass `B` in `pack2`, so LINE 3 compiles without error. C: **Incorrect:** LINE 3 (`protected`) is valid in a subclass across packages. D: **Correct:** LINE 1 fails because default (package-private) access is not visible outside `pack1`, and LINE 2 fails because `private` access is not visible outside class `A`.

Let us trace the execution of `java -ea AssertTest` (with assertions enabled) in chronological order: **1. Inside `main()`:** - `currentTemp = 35.0`, `idealTemp = 37.0`. - **`assert-4`**: `assert currentTemp >= -100 && currentTemp <= 150;` \( \rightarrow 35.0 \in [-100, 150] \) is `true` (passes). - Next, `caltempDiff(35.0, 37.0)` is called. **2. Inside `caltempDiff(35.0, 37.0)`:** - **`assert-1`**: `assert currentTemp >= -100 && currentTemp <= 150;` \( \rightarrow 35.0 \in [-100, 150] \) is `true` (passes). - **`assert-2`**: `assert idealTemp >= -100 && idealTemp <= 150;` \( \rightarrow 37.0 \in [-100, 150] \) is `true` (passes). - `tempdiff = currentTemp - idealTemp = 35.0 - 37.0 = -2.0`. - **`assert-3`**: `assert tempdiff >= 0;` \( \rightarrow -2.0 \ge 0 \) is **`false`**! This throws an `AssertionError`. **Answer: assert-3.** A: **Incorrect:** `currentTemp` is `35.0`, which satisfies `-100 <= 35.0 <= 150`, so `assert-1` passes. B: **Incorrect:** `idealTemp` is `37.0`, which satisfies `-100 <= 37.0 <= 150`, so `assert-2` passes. C: **Correct:** `tempdiff` is `35.0 - 37.0 = -2.0`, which violates `tempdiff >= 0`, causing `assert-3` to throw an `AssertionError`. D: **Incorrect:** `assert-4` runs first in `main()`, and since `35.0` is between `-100` and `150`, it passes.

Let us examine the array `appliances` and the classes inside it: **1. Array Element Type:** `private Object[] appliances = {new FrontLoadWasher(), new TopLoadWasher()};` Because the array is declared as `Object[]`, the compile-time type of `appliances[i]` is `Object`, which does not have a `showWashable()` method. **2. Common Interface Type (`Washable`):** - Both `FrontLoadWasher` and `TopLoadWasher` implement the `Washable` interface, which declares `void showWashable();`. - However, `FrontLoadWasher` and `TopLoadWasher` are sibling classes (neither extends the other), so casting `appliances[i]` to `FrontLoadWasher` or `TopLoadWasher` will throw a `ClassCastException` on one of the elements! - Casting to their common interface `((Washable) appliances[i]).showWashable();` safely invokes `showWashable()` polymorphically on both objects. **Answer: ((Washable) appliances[i]).showWashable();.** A: **Correct:** Both `FrontLoadWasher` and `TopLoadWasher` implement `Washable`, so casting `appliances[i]` to `Washable` compiles and runs without error. B: **Incorrect:** The compile-time type of `appliances[i]` is `Object`, which does not have a `showWashable()` method (compilation error). C: **Incorrect:** Throws a `ClassCastException` at runtime when `i = 1` because `TopLoadWasher` cannot be cast to `FrontLoadWasher`. D: **Incorrect:** Throws a `ClassCastException` at runtime when `i = 0` because `FrontLoadWasher` cannot be cast to `TopLoadWasher`.

Let us trace the Java Stream pipeline step by step: **1. `Stream.iterate(50, p -> p - 5)`:** Generates the infinite sequence of numbers starting at 50 and decreasing by 5 each step: \( 50, 45, 40, 35, 30, 25, 20, 15, \dots \) **2. `.map(p -> p * 2)`:** Multiplies each element by 2: \( 100, 90, 80, 70, 60, 50, 40, 30, \dots \) **3. `.filter(p -> p % 4 == 0)`:** Keeps only the mapped numbers that are divisible by 4: - \( 100 \div 4 = 25 \) (kept) - \( 90 \div 4 = 22.5 \) (filtered out) - \( 80 \div 4 = 20 \) (kept) - \( 70 \div 4 = 17.5 \) (filtered out) - \( 60 \div 4 = 15 \) (kept) - \( 50 \div 4 = 12.5 \) (filtered out) - \( 40 \div 4 = 10 \) (kept) **4. `.limit(4)` and `.forEach(...)`:** Takes the first 4 kept elements and prints them separated by spaces: `100 80 60 40`. **Answer: 100 80 60 40.** A: **Incorrect:** Forgets the `.map(p -> p * 2)` step and starts at 40 instead of 100. B: **Incorrect:** `90` and `70` are not divisible by 4, so they are removed by `.filter(p -> p % 4 == 0)`. C: **Correct:** Doubling `50, 45, 40, 35, 30, 25, 20` gives `100, 90, 80, 70, 60, 50, 40`, and filtering for multiples of 4 yields `100 80 60 40`. D: **Incorrect:** The stream subtracts 5 (`p -> p - 5`), so the values decrease rather than increase.

Let us trace how `LinkedHashSet` and `TreeSet` store the elements from `list` (`"Apple"`, `"Samsung"`, `"Nokia"`, `"Samsung"`): **1. `set1` (`LinkedHashSet<String>`):** - A `Set` does not allow duplicate elements, so the second `"Samsung"` is ignored. - `LinkedHashSet` preserves the **insertion order** of elements. - Therefore, iterating over `set1` prints: `Apple Samsung Nokia`. **2. `set2` (`TreeSet<String>`):** - `TreeSet` also eliminates duplicates, and stores elements in **natural alphabetical order**. - Alphabetically, `"Apple" < "Nokia" < "Samsung"`. - Therefore, iterating over `set2` prints: `Apple Nokia Samsung`. **Answer: Apple Samsung Nokia on the first line and Apple Nokia Samsung on the second line (Option A).** A: **Correct:** `LinkedHashSet` preserves insertion order (`Apple Samsung Nokia`) while `TreeSet` sorts elements alphabetically (`Apple Nokia Samsung`). B: **Incorrect:** Sets never contain duplicate elements (`Samsung Samsung`), and `TreeSet` sorts in ascending order. C: **Incorrect:** `TreeSet` sorts strings in ascending alphabetical order (`Apple Nokia Samsung`), not `Samsung Nokia Apple`. D: **Incorrect:** `LinkedHashSet` preserves insertion order starting with `Apple`, not `Nokia`.

Let us examine what happens at `//LINE 1` inside `class RollNumber<T extends Number>`: **1. Context of `genRollno(ARG)`:** - Inside `genRollno`, the code calls `r.getPart1().intValue()` and `r.getPart2().intValue()`. - Because the class itself is declared as `class RollNumber<T extends Number>`, every instantiation `RollNumber<...>` guarantees that its type parameter extends `Number`! Thus, `r.getPart1()` and `r.getPart2()` are guaranteed to be at least of type `Number`, which has `.intValue()`. **2. Checking Each Option for `ARG` when called as `r1.genRollno(r2)` (where `r1` and `r2` are `RollNumber<Integer>`):** - **Option A (`RollNumber<T> r`)**: Inside `r1` (which is `RollNumber<Integer>`), `T` is `Integer`. Thus `RollNumber<T>` is `RollNumber<Integer>`, which matches `r2` (`RollNumber<Integer>`). (**Valid**) - **Option B (`RollNumber<Number> r`)**: Because Java generics are invariant, `RollNumber<Integer>` cannot be passed to a parameter of type `RollNumber<Number>`. (**Compilation Error**) - **Option C (`RollNumber<?> r`)**: An unbounded wildcard `RollNumber<?>` accepts `RollNumber<Integer>`. Moreover, because `RollNumber` declares `<T extends Number>`, the upper bound of `?` is implicitly `Number`, so `r.getPart1().intValue()` compiles cleanly! (**Valid**) - **Option D (`RollNumber<Object> r`)**: `Object` does not extend `Number`, so `RollNumber<Object>` is illegal (`type argument Object is not within bounds of type-variable T`). (**Compilation Error**) **Answer: RollNumber<T> r and RollNumber<?> r (Options A and C).** A: **Correct:** Since `r1` and `r2` are both `RollNumber<Integer>`, `T` is `Integer` and `RollNumber<T> r` accepts `r2`. B: **Incorrect:** Due to generic invariance, `RollNumber<Integer>` is not a subtype of `RollNumber<Number>`. C: **Correct:** `RollNumber<?> r` accepts any `RollNumber` instantiation, and because `T extends Number`, `r.getPart1()` has upper bound `Number`, allowing `.intValue()`. D: **Incorrect:** `RollNumber<Object>` violates the class bound `<T extends Number>` because `Object` is not a subclass of `Number`.

We want to filter the `List<WaterFilter> filters` so that only filters with `5.0 <= flowRate <= 15.0` remain as `WaterFilter` objects, and then print `f.name` for each: - **Option A**: Uses `.map(f -> f.flowRate >= 5.0 && f.flowRate <= 15.0)`, which transforms the stream into a `Stream<Boolean>`. Then `.forEach(f -> System.out.println(f.name))` fails to compile because a `Boolean` does not have a `.name` field. - **Option B**: Uses a single `.filter(f -> f.flowRate >= 5.0 && f.flowRate <= 15.0)` followed by `.forEach(f -> System.out.println(f.name))`. This keeps only matching `WaterFilter` objects and prints their names. (**Correct**) - **Option C**: Chains two `.filter()` calls: `.filter(f -> f.flowRate >= 5.0).filter(f -> f.flowRate <= 15.0)`, which is logically identical to the `&&` condition, followed by `.forEach(f -> System.out.println(f.name))`. (**Correct**) - **Option D**: Uses `.map(f -> f.flowRate <= 15.0)` as the second step, turning the stream into `Stream<Boolean>`, which fails to compile on `f.name`. **Answer: Options B and C.** A: **Incorrect:** `.map(...)` converts each `WaterFilter` into a `Boolean`, causing a compilation error when trying to access `f.name`. B: **Correct:** Filters the stream of `WaterFilter` objects using the compound condition `f.flowRate >= 5.0 && f.flowRate <= 15.0` and prints `f.name`. C: **Correct:** Chaining `.filter(f -> f.flowRate >= 5.0)` and `.filter(f -> f.flowRate <= 15.0)` keeps elements satisfying both bounds and prints `f.name`. D: **Incorrect:** The second stage uses `.map(...)` instead of `.filter(...)`, converting the stream elements to `Boolean` so `f.name` cannot be resolved.

In Java, **type erasure** replaces generic type parameters with their upper bounds (or `Object` if unbounded) at compile time: **1. `public <T extends Number> void calculateSum(T[] marks)`:** Here `T` is bounded by `Number` (`<T extends Number>`), so `T` is erased to its upper bound `Number`. The method signature becomes: `public void calculateSum(Number[] marks)` **2. `public <T> void displayMarks(T[] marks)`:** Here `T` is **unbounded** (`<T>`), so `T` is erased to `Object`. The method signature becomes: `public void displayMarks(Object[] marks)` **3. `public <T extends Number> double calculateAverage(List<T> marks)`:** Here `T` is bounded by `Number`, and the return type is already `double`. Thus, after erasing `<T extends Number>`, it corresponds to Option B: `public double calculateAverage(List<Number> marks)`. **Answer: Option B.** A: **Incorrect:** Erases `<T extends Number>` in `calculateSum` to `Object[]` instead of its upper bound `Number[]`, and changes the return type of `calculateAverage` from `double` to `Object`. B: **Correct:** Bounded `<T extends Number>` is replaced by `Number`, while unbounded `<T>` in `displayMarks` is replaced by `Object`. C: **Incorrect:** Retains `<T> T` in `calculateAverage` instead of erasing the type parameter and keeping the `double` return type. D: **Incorrect:** Retains all the `<T>` generic type parameters instead of erasing them.