Programming Concepts using Java · Quiz 1 · Jan 2025

**1. Follow the displayed method calls:** main invokes methodThree(), which invokes methodTwo(), which invokes methodOne(). Each remains active while the next executes. **2. Count the program frames:** The four frames are main, methodThree, methodTwo and methodOne. At the deepest point all four coexist. **Answer: A — 4.** **Convention note:** The textbook count concerns the four displayed methods and treats ellipses as irrelevant noncalling work. Constructor execution and JVM startup internals are not added to this intended count; a literal count of every frame ever created would require those details. A: **Correct:** All four displayed method invocations are included. B: **Incorrect:** This omits main’s activation record. C: **Incorrect:** The intended method-call count is four, not five. D: **Incorrect:** This misses two active methods.

**1. Apply the subtype direction:** In the stated model, SeniorProgrammer supplies writeCode(), debugCode() and the extra reviewCode(). It supports the Programmer operations, so it can be used where a Programmer is expected. **2. Test the reverse substitution:** An ordinary Programmer need not support reviewCode(). It cannot generally replace a SeniorProgrammer. Thus D is the incorrect claim. **Answer: D — Subtyping allows Programmer to be used wherever a SeniorProgrammer is .** **Convention note:** Matching method names alone is not a full behavioral-subtyping proof; required behavior must be preserved, and Java also requires a declared nominal subtype relationship. The question assumes that relationship and the usual compatible behavior. A: **Incorrect:** True in the question’s subtype model, so not selected: the senior type supports all required programmer operations. B: **Incorrect:** True, so not selected: the ordinary programmer lacks the required additional method. C: **Incorrect:** True, so not selected: substituting the subtype for its supertype is the intended direction. D: **Correct:** False, so selected: substitution does not generally work from a supertype to its subtype.

**1. Execute the do-while:** number begins at 10 and decreases to 9,8,7,6,5. Once it is 5, the test number>5 becomes false. **2. Select the switch case:** case 5 prints “Low” and breaks. Neither case 6 nor default executes. **Answer: A — Low.** A: **Correct:** The switch value is exactly 5. B: **Incorrect:** Medium requires switch value 6, but the loop continues from 6 to 5. C: **Incorrect:** High is in default, which is not reached. D: **Incorrect:** Unknown is in default, which is not reached.

**1. Execute constructors:** new Grapes() first calls Fruits(), printing “Fruit created!”, then continues Grapes(), printing “Grape created!”. **2. Dispatch display():** The reference a has type Fruits but holds a Grapes object. The overridden display() therefore prints “Grapes!”. **Answer: B — Fruit created!; Grape created!; Grapes!.** A: **Incorrect:** The constructors are correct, but display() uses Grapes’ override, not Fruits’ body. B: **Correct:** The superclass constructor, subclass constructor and subclass display run in order. C: **Incorrect:** The superclass constructor necessarily executes and prints first. D: **Incorrect:** This both omits the superclass constructor message and uses the wrong display implementation.

**1. Type-check the intended equality method:** obj is Object. B tests instanceof Player and casts to Player before accessing the two private fields, which is legal from within Player. **2. Evaluate the intended example:** With both objects constructed as Player("004","Red"), the identical literals share interned String references, so B’s == comparisons evaluate true and print “p1 and p2 are same”. **Answer: B — instanceof Player followed by an explicit Player cast.** **Convention note:** The PDF mistakenly writes Player p2=new Car("004","Red"); no Car class is supplied. No equals-body insertion can repair that literal listing. B is the intended answer after replacing Car with Player and supplying the indicated constructor. For general string-content equality use String.equals or Objects.equals instead of ==, and implement a consistent hashCode. A: **Incorrect:** Object does not expose Player fields, even inside an ordinary instanceof branch without a cast. B: **Correct:** The explicit Player cast exposes the fields, and the interned literals compare equal by reference for this example. C: **Incorrect:** obj has declared type Object, so direct field access fails to compile. D: **Incorrect:** Player p=obj requires an explicit cast; ordinary instanceof does not change obj’s declared type.

**1. Separate object capability from reference type:** Car implements both Vehicle and Fuel, inheriting refuel() from Fuel and overriding drive(). But v1 is declared Vehicle, which does not expose refuel(). **2. Resolve the invalid call:** v1.drive() is legal, while v1.refuel() at LINE 1 fails member lookup at compile time. The complete program therefore prints nothing. **Answer: D — Compilation error at LINE 1: Vehicle does not expose refuel().** A: **Incorrect:** Those messages would require a Fuel/Car reference or cast for refuel(); the current call does not compile. B: **Incorrect:** The code fails to compile, and drive() would select Car’s override if repaired. C: **Incorrect:** Car inherits a complete default refuel(), so its concrete declaration is valid. D: **Correct:** The declared Vehicle type has no refuel() method.

**1. Track the three references:** b2 is a separate Book produced by the shallow copy constructor; b3 aliases b1. Both Book objects share the same authors array. **2. Apply each update:** b2.name becomes Nirmala independently. Setting b2.authors[0] changes the shared array to start with Laxmana. Thus b1 and b3 print “Gita, Laxmana”, while b2 prints “Nirmala, Laxmana”. **Answer: A — Gita, Laxmana; Nirmala, Laxmana; Gita, Laxmana.** A: **Correct:** The names remain separate while every reference observes the mutated shared array. B: **Incorrect:** The shared array change is also visible through b1 and b3. C: **Incorrect:** Changing b2.name does not change b1.name; the array mutation also reaches all three reads. D: **Incorrect:** Neither b1 nor its alias b3 changes name when b2.name is reassigned.

**1. Follow the no-argument override:** obj refers to SmartFan, so obj.turnOn() calls SmartFan.turnOn(). Its super.turnOn() prints “Turn on fan”, then its own body prints “Turn on smart fan with default settings”. **2. Resolve the int overload:** SmartFan does not override turnOn(int). The inherited Fan.turnOn(3) prints “Set fan speed to: 3”. **Answer: A — Turn on fan; Turn on smart fan with default settings; Set fan speed to: 3.** A: **Correct:** This includes both explicit no-argument messages followed by the inherited int overload. B: **Incorrect:** The assignment actually uses Fan obj=new SmartFan(), which is valid; the claim describes a different assignment. C: **Incorrect:** The applicable signatures and dynamic override are unambiguous. D: **Incorrect:** This omits SmartFan’s own message after super.turnOn().

**1. Identify the real compilation problems:** LINE 1 attempts to override final calculateInterest(); LINE 2 accesses private interestRate from SavingsAccount; LINE 3 assigns a general BankAccount object to a SavingsAccount reference. **2. Select the false assertion:** LINE 4 widens a SavingsAccount object to a BankAccount reference, which is allowed. The assertion claiming that this line is invalid is false. **Answer: D — the claim that LINE 4 is invalid is false.** **Convention note:** In B, interestRate is actually a private static field, not an instance field. Its stated access failure is nevertheless correct; D is the intended false claim about reference compatibility. A: **Incorrect:** True statement, not selected: the final superclass method cannot be overridden. B: **Incorrect:** The private-field access error is real, so do not select; the option loosely calls interestRate an instance variable although its declaration is static. C: **Incorrect:** True statement, not selected: a newly created ordinary BankAccount is not a SavingsAccount. D: **Correct:** False statement, selected: a BankAccount reference may hold a SavingsAccount object.

**1. Leave the incomplete type abstract:** Flyable requires takeOff(). Bird supplies fly() but leaves takeOff() for subclasses, so it must be an abstract class implementing Flyable. **2. Complete the subtype:** Sparrow extends Bird and implements takeOff(). Calls through Flyable run Bird.fly() and Sparrow.takeOff(), printing “Bird: Flying high” and “Sparrow taking off”. **Answer: B — abstract class Bird implements Flyable with fly() printing Bird: Flying high.** A: **Incorrect:** Concrete Bird cannot leave takeOff() unimplemented. B: **Correct:** The abstract class can provide fly() and defer takeOff() to Sparrow. C: **Incorrect:** An interface extends other interfaces rather than implements them; Sparrow’s class-extends clause would also be invalid. D: **Incorrect:** Sparrow cannot extend an interface as a class, and the shown ordinary interface method body lacks default or static.

**1. Supply the callback:** Waitstaff implements OrderCallback, so passing this to Chef’s constructor is legal. Chef stores this reference to notify the same Waitstaff object. **2. Follow the three prints:** prepareDish("pasta") prints “Chef: Preparing pasta...” and “Chef: pasta is ready.”, then invokes callback.onOrderReady(), which prints “Waitstaff: pasta served!”. **Answer: D — Chef: Preparing pasta...; Chef: pasta is ready.; Waitstaff: pasta served!.** A: **Incorrect:** A callback-implementing object is a valid argument to the interface-typed constructor. B: **Incorrect:** The callback is initialized, and calling back to Waitstaff is legal. C: **Incorrect:** The interface declares onOrderReady(), so the invocation compiles. D: **Correct:** The two Chef messages are followed by the Waitstaff callback message.

**1. Resolve the initial call:** obj is Appliance-typed but refers to a WashingMachine. turnOn() dispatches to the subclass and prints “Washing machine is turned on”. **2. Access the subclass-only operation:** Appliance does not declare startWashCycle(), so cast to WashingMachine. Both C’s guarded cast and D’s direct cast are valid for the actual object and print “Wash cycle starts”. **Answer: C, D — C and D — guarded or direct WashingMachine downcast.** A: **Incorrect:** The declared Appliance type does not expose startWashCycle(). B: **Incorrect:** This is a nonstatic instance method and cannot be called through the class name alone. C: **Correct:** The instanceof check succeeds, and the cast makes the subclass method visible. D: **Correct:** The actual WashingMachine object makes this direct downcast safe.

**1. Choose the returned implementation:** ins1 has age 20. Since 20>25 is false, checkEligibility() returns a NotEligibleForClaim object through the ClaimEligibility interface. **2. Invoke the interface operation:** A stores that return value and calls printEligibility(); B calls it immediately on the returned value. Both print “Not eligible for Insurance Claim”. **Answer: A, B — A and B — store or immediately invoke the returned ClaimEligibility.** A: **Correct:** The interface reference exposes printEligibility() and dispatches to the returned noneligible implementation. B: **Correct:** Chaining invokes printEligibility() on the same kind of returned interface object. C: **Incorrect:** Insurance itself does not declare printEligibility(). D: **Incorrect:** EligibleForClaim is a private inner class, not an instance field or static method path on ins1; it is also not the selected branch.