Q: In Java (control flow with i++ and --j inside a do-while), what are the final values printed? int i = 1, j = 10; do { if(i++ > --j) /* Line 4 / { continue; } } while (i < 5); System.out.println("i = " + i + " and j = " + j); / Line 9 */

Introduction / Context: This problem exercises short, precise reasoning about post-increment and pre-decrement inside a conditional, plus the behavior of continue within a do-while loop. Understanding evaluation order is crucial to get the final values correct. Given Data / Assumptions: Start with i = 1, j = 10. Condition checks i++ (returns old i, then increments) and --j (decrements then returns). continue skips to the while-condition check at the loop bottom. Concept / Approach: Trace each iteration carefully and update i and j in the exact order the expression evaluates: left operand i++ first (post-increment), right operand --j second (pre-decrement), then compare. The body has no other state changes except potential continue (which still executes the loop condition afterward). Step-by-Step Solution: Iter1: i++ yields 1 → i=2; --j yields 9 → compare 1>9 false; condition i 8 false; i 7 false; i 6 false; i<5 now false (i=5) → exit Verification / Alternative check: Because the if-condition never becomes true, continue never fires; only the implicit increments from the condition update i and j each time. Final: i = 5, j = 6. Why Other Options Are Wrong: Other pairs assume a different number of iterations or reversed increment/decrement order. Common Pitfalls: Forgetting that i++ returns the old value while still incrementing afterward; and that --j decrements before comparison. Final Answer: i = 5 and j = 6

Q: In Java (String vs StringBuilder API), what is the output or error? String d = "bookkeeper"; d.substring(1, 7); d = "w" + d; d.append("woo"); /* Line 4 */ System.out.println(d);

Introduction / Context: This snippet distinguishes between the APIs of immutable String and mutable StringBuilder/StringBuffer. It also highlights that ignoring the return value of substring does not change the original String, and that append is not a member of String at all. Given Data / Assumptions: d is declared as String. d.substring(1,7) is called but its result is discarded. d = "w" + d; creates a new String. d.append("woo") is attempted on a String. Concept / Approach: Only StringBuilder and StringBuffer provide append. Invoking append on a String is a compile-time error: cannot find symbol: method append(java.lang.String). If a mutable sequence was intended, declare StringBuilder d = new StringBuilder("bookkeeper"); and then use d.append(...). Step-by-Step Solution: Compilation step: the call d.append("woo") fails because String has no such method. Therefore the program does not run; no runtime output is produced. Verification / Alternative check: If we replaced line 4 with d = d + "woo";, output would be wbookkeeperwoo. If we used StringBuilder, we could build efficiently without intermediate strings. Why Other Options Are Wrong: They assume either append exists on String or that substring mutated the original; neither is true. Common Pitfalls: Treating Strings as mutable, or assuming substring changes the receiver. Always capture returned values from String operations. Final Answer: Compilation fails.

Q: In Java (IEEE 754 math), what does the following print? System.out.println(Math.sqrt(-4D));

Introduction / Context: Java’s Math library follows IEEE 754 floating-point rules. The square root of a negative real number is not defined in the reals, so Math.sqrt returns the special floating-point value NaN (Not-a-Number) rather than throwing an exception. Given Data / Assumptions: Argument is -4D, a double literal. We are using Math.sqrt(double). Concept / Approach: For negative inputs, many Math functions are defined to return NaN. Java does not use exceptions for these domain errors in the Math class; instead, it propagates NaN, which prints as the string "NaN". Step-by-Step Solution: Compute sqrt(-4D) under IEEE 754 → NaN System.out prints "NaN" Verification / Alternative check: Double.isNaN(Math.sqrt(-4)) returns true. To compute square roots of negative numbers as complex values, use a complex number library instead of Math.sqrt. Why Other Options Are Wrong: -2: would be the real square root of +4, not -4. Compile Error / Runtime Exception: not thrown for this method. Infinity: returned by operations like division by zero for nonzero numerators, not here. Common Pitfalls: Expecting exceptions from Math for domain errors; in Java, NaN is the standard signal value. Final Answer: NaN

Q: In Java (parsing and rounding), what does this code print? public class NFE { public static void main(String [] args) { String s = "42"; try { s = s.concat(".5"); /* Line 8 */ double d = Double.parseDouble(s); s = Double.toString(d); int x = (int) …

Introduction / Context: This snippet chains parsing, formatting, and rounding. The key is understanding that Math.ceil rounds up to the nearest integer (as a double) and that casting to int then truncates toward zero, preserving the rounded integer value in this case. Given Data / Assumptions: Start s = "42", then s.concat(".5") → "42.5". Double.parseDouble("42.5") succeeds, producing 42.5. Math.ceil(42.5) = 43.0. Cast 43.0 to int → 43. Concept / Approach: Double.valueOf(s).doubleValue() is redundant after parsing, but it returns the same double. Math.ceil returns a double whose value is the smallest integer greater than or equal to the argument. Casting this value to int simply yields that integer. Step-by-Step Solution: s = "42" → s = "42.5" d = 42.5 ceil(42.5) = 43.0 (int)43.0 = 43 Print 43 Verification / Alternative check: Had the code used Math.floor, the result would be 42. Using Math.round(42.5) would yield 43 as well (ties go to +∞ for positive halves in Java’s round-to-nearest-even? Actually, round(42.5) = 43 in Java). Why Other Options Are Wrong: 42 or 42.5: ignore the effect of ceil and integer casting. "bad number": parsing "42.5" is valid for Double. Common Pitfalls: Expecting a NumberFormatException from "42.5"; that would occur for Integer.parseInt, not Double.parseDouble. Final Answer: 43

Q: In Java (String immutability and concatenation), what is printed? String s = "ABC"; s.toLowerCase(); s += "def"; System.out.println(s);

Introduction / Context: Here we check whether calling toLowerCase() without assignment changes a String and how concatenation with += works for immutable Strings in Java. The operation order determines the final printed value. Given Data / Assumptions: s is initially "ABC". s.toLowerCase() result is ignored. s += "def" concatenates and reassigns to s. Concept / Approach: Strings are immutable; methods return new objects rather than mutating the original. If you do not store the returned String from toLowerCase(), s remains unchanged ("ABC"). The += operation creates a new String "ABCdef" and assigns it to s. Step-by-Step Solution: s = "ABC" s.toLowerCase(); // no assignment → s still "ABC" s = s + "def" → "ABCdef" Print "ABCdef" Verification / Alternative check: If you wanted "abcdef", you would need s = s.toLowerCase(); before concatenation or write ("ABC".toLowerCase() + "def"). Why Other Options Are Wrong: "ABC" ignores the concatenation. "abc"/"abcdef" require assigning the lowercase result. Compile Error: code is valid. Common Pitfalls: Expecting String methods to mutate the instance; they never do. Always store the returned value when transformation is desired. Final Answer: ABCdef

Q: In Java (operators, short-circuiting, and identifiers), what is the output of this program or what error occurs? public class ExamQuestion6 { static int x; boolean catch() { x++; return true; } public static void main(String[] args) { x = 0; if ((c…

Introduction / Context: This question examines two ideas: (1) whether Java allows keywords as identifiers, and (2) the evaluation behavior of | versus ||. The crucial blocker here is the method name catch, which is a reserved keyword in Java and cannot be used as an identifier. Given Data / Assumptions: Method declared as boolean catch() in the same class. The main method is static; even if naming were legal, calling an instance method without an instance would also be problematic unless qualified. Concept / Approach: Java’s reserved words (e.g., catch, try, class) cannot be used as method or variable names. Therefore, the code fails to compile before any runtime evaluation occurs. If it were renamed (e.g., call()) and made static or invoked on an instance, note that | (bitwise-or on booleans) evaluates both operands (no short-circuit), while || short-circuits the right operand when the left is true. Step-by-Step Solution: Compilation stage: identifier catch conflicts with Java keyword → error. Program does not execute; no output is produced. Verification / Alternative check: Renaming the method to f() and making it static, the expression (f() | f()) || f() would call f() twice on the left (because | is non–short-circuit) and possibly skip the final f() depending on results. Why Other Options Are Wrong: Numeric outputs assume successful compilation and execution, which do not occur. Runtime Exception: never reached due to compile failure. Common Pitfalls: Forgetting that some symbols cannot be identifiers; also mixing up | (always evaluates both sides) vs || (short-circuits). Final Answer: Compilation Fails

Q: In Java, wrapper conversions and numeric promotions: predict the output printed by this try-catch code. try { Float f1 = new Float("3.0"); int x = f1.intValue(); byte b = f1.byteValue(); double d = f1.doubleValue(); System.out.println(x + b + …

Introduction / Context: This Java snippet tests knowledge of wrapper classes, primitive extraction methods, and numeric promotion rules during arithmetic and string output. A Float object is created from the string literal "3.0" and then converted to int, byte, and double before being summed and printed inside a try-catch that targets NumberFormatException. Given Data / Assumptions: f1 is constructed as new Float("3.0"). x = f1.intValue() returns 3. b = f1.byteValue() returns 3. d = f1.doubleValue() returns 3.0. System.out.println uses arithmetic addition because the first operator is numeric, not string concatenation. Concept / Approach: Autounboxing is not even required here because we explicitly call value methods. The expression x + b + d performs left-to-right evaluation with numeric promotion: int + byte becomes int, yielding 6, then 6 + double promotes to double, yielding 9.0. No parsing error occurs, so the catch block is not entered. Step-by-Step Solution: Evaluate x = 3.Evaluate b = 3.Evaluate d = 3.0.Compute x + b → 3 + 3 = 6 (int).Compute 6 + d → 6 + 3.0 = 9.0 (double).Print 9.0. Verification / Alternative check: If the code had used string concatenation like "" + x + b + d, the result would be the string "33.0". Because it starts with numeric types, Java performs arithmetic. Why Other Options Are Wrong: bad number: No NumberFormatException occurs for "3.0". Compilation fails…: The code is syntactically valid. 3.03.0: That would require string concatenation from the first operand. Common Pitfalls: Assuming string concatenation, or expecting NumberFormatException for a valid decimal string. Final Answer: 9.0

Q: Java booleans, wrapper Boolean, and the single ampersand operator: determine the output (JDK 1.6+). public class BoolTest { public static void main(String[] args) { Boolean b1 = new Boolean("false"); boolean b2; b2 = b1.booleanValue(); if (!b2…

Introduction / Context: The task probes differences between primitive boolean and wrapper Boolean, the effect of booleanValue(), and the semantics of the single ampersand operator (&) in boolean expressions, which evaluates both operands but still returns a boolean result. Given Data / Assumptions: b1 = new Boolean("false") so b1.booleanValue() is false. First if uses !b2, which is true because b2 is false. Single & is a non-short-circuit boolean operator. Output tokens have trailing spaces as shown. Concept / Approach: After the first if block, b2 becomes true and "x " is printed. The second condition evaluates (b1 & b2) → (false & true) which is false, so the body is skipped. Finally, println prints "z" on the same line after a space from the previous print. Step-by-Step Solution: b1 = Boolean(false).b2 = b1.booleanValue() → false.if (!b2) → true → set b2 = true; print "x ".if (b1 & b2) → false & true → false → do not print "y ".println("z") → prints z, resulting in "x z". Verification / Alternative check: Replacing & with && would short-circuit, but the result would still be false for (false && true), producing the same printed tokens. Why Other Options Are Wrong: z: Misses the earlier "x ". y z / x y z: The condition for y is false. Compilation fails: All types and methods are valid. Common Pitfalls: Confusing & (non-short-circuit) with && (short-circuit); misunderstanding wrapper vs primitive behavior. Final Answer: x z

Question 1

In Java (control flow with i++ and --j inside a do-while), what are the final values printed?  int i = 1, j = 10; do { if(i++ > --j) /* Line 4 / { continue; } } while (i < 5); System.out.println("i = " + i + " and j = " + j); / Line 9 */

Accepted Answer

Introduction / Context: This problem exercises short, precise reasoning about post-increment and pre-decrement inside a conditional, plus the behavior of continue within a do-while loop. Understanding evaluation order is crucial to get the final values correct. Given Data / Assumptions: Start with i = 1, j = 10. Condition checks i++ (returns old i, then increments) and --j (decrements then returns). continue skips to the while-condition check at the loop bottom. Concept / Approach: Trace each iteration carefully and update i and j in the exact order the expression evaluates: left operand i++ first (post-increment), right operand --j second (pre-decrement), then compare. The body has no other state changes except potential continue (which still executes the loop condition afterward). Step-by-Step Solution: Iter1: i++ yields 1 → i=2; --j yields 9 → compare 1>9 false; condition i<5 true (i=2) Iter2: i++ yields 2 → i=3; --j yields 8 → 2>8 false; i<5 true Iter3: i++ yields 3 → i=4; --j yields 7 → 3>7 false; i<5 true Iter4: i++ yields 4 → i=5; --j yields 6 → 4>6 false; i<5 now false (i=5) → exit Verification / Alternative check: Because the if-condition never becomes true, continue never fires; only the implicit increments from the condition update i and j each time. Final: i = 5, j = 6. Why Other Options Are Wrong: Other pairs assume a different number of iterations or reversed increment/decrement order. Common Pitfalls: Forgetting that i++ returns the old value while still incrementing afterward; and that --j decrements before comparison. Final Answer: i = 5 and j = 6

Question 2

In Java (String vs StringBuilder API), what is the output or error?  String d = "bookkeeper"; d.substring(1, 7); d = "w" + d; d.append("woo"); /* Line 4 */ System.out.println(d);

Accepted Answer

Introduction / Context: This snippet distinguishes between the APIs of immutable String and mutable StringBuilder/StringBuffer. It also highlights that ignoring the return value of substring does not change the original String, and that append is not a member of String at all. Given Data / Assumptions: d is declared as String. d.substring(1,7) is called but its result is discarded. d = "w" + d; creates a new String. d.append("woo") is attempted on a String. Concept / Approach: Only StringBuilder and StringBuffer provide append. Invoking append on a String is a compile-time error: cannot find symbol: method append(java.lang.String). If a mutable sequence was intended, declare StringBuilder d = new StringBuilder("bookkeeper"); and then use d.append(...). Step-by-Step Solution: Compilation step: the call d.append("woo") fails because String has no such method. Therefore the program does not run; no runtime output is produced. Verification / Alternative check: If we replaced line 4 with d = d + "woo";, output would be wbookkeeperwoo. If we used StringBuilder, we could build efficiently without intermediate strings. Why Other Options Are Wrong: They assume either append exists on String or that substring mutated the original; neither is true. Common Pitfalls: Treating Strings as mutable, or assuming substring changes the receiver. Always capture returned values from String operations. Final Answer: Compilation fails.

Question 3

In Java (IEEE 754 math), what does the following print?  System.out.println(Math.sqrt(-4D));

Accepted Answer

Introduction / Context: Java’s Math library follows IEEE 754 floating-point rules. The square root of a negative real number is not defined in the reals, so Math.sqrt returns the special floating-point value NaN (Not-a-Number) rather than throwing an exception. Given Data / Assumptions: Argument is -4D, a double literal. We are using Math.sqrt(double). Concept / Approach: For negative inputs, many Math functions are defined to return NaN. Java does not use exceptions for these domain errors in the Math class; instead, it propagates NaN, which prints as the string "NaN". Step-by-Step Solution: Compute sqrt(-4D) under IEEE 754 → NaN System.out prints "NaN" Verification / Alternative check: Double.isNaN(Math.sqrt(-4)) returns true. To compute square roots of negative numbers as complex values, use a complex number library instead of Math.sqrt. Why Other Options Are Wrong: -2: would be the real square root of +4, not -4. Compile Error / Runtime Exception: not thrown for this method. Infinity: returned by operations like division by zero for nonzero numerators, not here. Common Pitfalls: Expecting exceptions from Math for domain errors; in Java, NaN is the standard signal value. Final Answer: NaN

Question 4

In Java (parsing and rounding), what does this code print?  public class NFE { public static void main(String [] args) { String s = "42"; try { s = s.concat(".5"); /* Line 8 */ double d = Double.parseDouble(s); s = Double.toString(d); int x = (int) …

Accepted Answer

Introduction / Context: This snippet chains parsing, formatting, and rounding. The key is understanding that Math.ceil rounds up to the nearest integer (as a double) and that casting to int then truncates toward zero, preserving the rounded integer value in this case. Given Data / Assumptions: Start s = "42", then s.concat(".5") → "42.5". Double.parseDouble("42.5") succeeds, producing 42.5. Math.ceil(42.5) = 43.0. Cast 43.0 to int → 43. Concept / Approach: Double.valueOf(s).doubleValue() is redundant after parsing, but it returns the same double. Math.ceil returns a double whose value is the smallest integer greater than or equal to the argument. Casting this value to int simply yields that integer. Step-by-Step Solution: s = "42" → s = "42.5" d = 42.5 ceil(42.5) = 43.0 (int)43.0 = 43 Print 43 Verification / Alternative check: Had the code used Math.floor, the result would be 42. Using Math.round(42.5) would yield 43 as well (ties go to +∞ for positive halves in Java’s round-to-nearest-even? Actually, round(42.5) = 43 in Java). Why Other Options Are Wrong: 42 or 42.5: ignore the effect of ceil and integer casting. "bad number": parsing "42.5" is valid for Double. Common Pitfalls: Expecting a NumberFormatException from "42.5"; that would occur for Integer.parseInt, not Double.parseDouble. Final Answer: 43

Question 5

In Java (String immutability and concatenation), what is printed?  String s = "ABC"; s.toLowerCase(); s += "def"; System.out.println(s);

Accepted Answer

Introduction / Context: Here we check whether calling toLowerCase() without assignment changes a String and how concatenation with += works for immutable Strings in Java. The operation order determines the final printed value. Given Data / Assumptions: s is initially "ABC". s.toLowerCase() result is ignored. s += "def" concatenates and reassigns to s. Concept / Approach: Strings are immutable; methods return new objects rather than mutating the original. If you do not store the returned String from toLowerCase(), s remains unchanged ("ABC"). The += operation creates a new String "ABCdef" and assigns it to s. Step-by-Step Solution: s = "ABC" s.toLowerCase(); // no assignment → s still "ABC" s = s + "def" → "ABCdef" Print "ABCdef" Verification / Alternative check: If you wanted "abcdef", you would need s = s.toLowerCase(); before concatenation or write ("ABC".toLowerCase() + "def"). Why Other Options Are Wrong: "ABC" ignores the concatenation. "abc"/"abcdef" require assigning the lowercase result. Compile Error: code is valid. Common Pitfalls: Expecting String methods to mutate the instance; they never do. Always store the returned value when transformation is desired. Final Answer: ABCdef

Question 6

In Java (operators, short-circuiting, and identifiers), what is the output of this program or what error occurs?  public class ExamQuestion6 { static int x; boolean catch() { x++; return true; } public static void main(String[] args) { x = 0; if ((c…

Accepted Answer

Introduction / Context: This question examines two ideas: (1) whether Java allows keywords as identifiers, and (2) the evaluation behavior of | versus ||. The crucial blocker here is the method name catch, which is a reserved keyword in Java and cannot be used as an identifier. Given Data / Assumptions: Method declared as boolean catch() in the same class. The main method is static; even if naming were legal, calling an instance method without an instance would also be problematic unless qualified. Concept / Approach: Java’s reserved words (e.g., catch, try, class) cannot be used as method or variable names. Therefore, the code fails to compile before any runtime evaluation occurs. If it were renamed (e.g., call()) and made static or invoked on an instance, note that | (bitwise-or on booleans) evaluates both operands (no short-circuit), while || short-circuits the right operand when the left is true. Step-by-Step Solution: Compilation stage: identifier catch conflicts with Java keyword → error. Program does not execute; no output is produced. Verification / Alternative check: Renaming the method to f() and making it static, the expression (f() | f()) || f() would call f() twice on the left (because | is non–short-circuit) and possibly skip the final f() depending on results. Why Other Options Are Wrong: Numeric outputs assume successful compilation and execution, which do not occur. Runtime Exception: never reached due to compile failure. Common Pitfalls: Forgetting that some symbols cannot be identifiers; also mixing up | (always evaluates both sides) vs || (short-circuits). Final Answer: Compilation Fails

Question 7

In Java, wrapper conversions and numeric promotions: predict the output printed by this try-catch code.  try {  Float f1 = new Float("3.0");  int x = f1.intValue();  byte b = f1.byteValue();  double d = f1.doubleValue();  System.out.println(x + b + …

Accepted Answer

Introduction / Context: This Java snippet tests knowledge of wrapper classes, primitive extraction methods, and numeric promotion rules during arithmetic and string output. A Float object is created from the string literal "3.0" and then converted to int, byte, and double before being summed and printed inside a try-catch that targets NumberFormatException. Given Data / Assumptions: f1 is constructed as new Float("3.0"). x = f1.intValue() returns 3. b = f1.byteValue() returns 3. d = f1.doubleValue() returns 3.0. System.out.println uses arithmetic addition because the first operator is numeric, not string concatenation. Concept / Approach: Autounboxing is not even required here because we explicitly call value methods. The expression x + b + d performs left-to-right evaluation with numeric promotion: int + byte becomes int, yielding 6, then 6 + double promotes to double, yielding 9.0. No parsing error occurs, so the catch block is not entered. Step-by-Step Solution: Evaluate x = 3.Evaluate b = 3.Evaluate d = 3.0.Compute x + b → 3 + 3 = 6 (int).Compute 6 + d → 6 + 3.0 = 9.0 (double).Print 9.0. Verification / Alternative check: If the code had used string concatenation like "" + x + b + d, the result would be the string "33.0". Because it starts with numeric types, Java performs arithmetic. Why Other Options Are Wrong: bad number: No NumberFormatException occurs for "3.0". Compilation fails…: The code is syntactically valid. 3.03.0: That would require string concatenation from the first operand. Common Pitfalls: Assuming string concatenation, or expecting NumberFormatException for a valid decimal string. Final Answer: 9.0

Question 8

Java booleans, wrapper Boolean, and the single ampersand operator: determine the output (JDK 1.6+).  public class BoolTest {  public static void main(String[] args) {  Boolean b1 = new Boolean("false");  boolean b2;  b2 = b1.booleanValue();  if (!b2…

Accepted Answer

Introduction / Context: The task probes differences between primitive boolean and wrapper Boolean, the effect of booleanValue(), and the semantics of the single ampersand operator (&) in boolean expressions, which evaluates both operands but still returns a boolean result. Given Data / Assumptions: b1 = new Boolean("false") so b1.booleanValue() is false. First if uses !b2, which is true because b2 is false. Single & is a non-short-circuit boolean operator. Output tokens have trailing spaces as shown. Concept / Approach: After the first if block, b2 becomes true and "x " is printed. The second condition evaluates (b1 & b2) → (false & true) which is false, so the body is skipped. Finally, println prints "z" on the same line after a space from the previous print. Step-by-Step Solution: b1 = Boolean(false).b2 = b1.booleanValue() → false.if (!b2) → true → set b2 = true; print "x ".if (b1 & b2) → false & true → false → do not print "y ".println("z") → prints z, resulting in "x z". Verification / Alternative check: Replacing & with && would short-circuit, but the result would still be false for (false && true), producing the same printed tokens. Why Other Options Are Wrong: z: Misses the earlier "x ". y z / x y z: The condition for y is false. Compilation fails: All types and methods are valid. Common Pitfalls: Confusing & (non-short-circuit) with && (short-circuit); misunderstanding wrapper vs primitive behavior. Final Answer: x z

Java.lang Class Questions