Working with Java Data Types practice questions

Worked examples for Working with Java Data Types

1. Question 1

   What is the output of the following program? ```java public class Main { public static void main(String[] args) { char a = 'a'; char b = 'b'; System.out.println(a + b + "" + (char) (a + 1)); } } ```

   1. A. abb

      This treats a + b as joining two characters; before any String operand appears, + on chars is numeric addition.

   2. B. ab195

      This has the order backwards — the char addition happens before the empty string and is numeric, and concatenation only takes over after it.

   3. C. 195bCorrect answer

      Before the empty string a + b is numeric (97 + 98 = 195); after it concatenation takes over, and (char)(97 + 1) is 'b', giving "195b" (JLS 8 §5.6.2, §15.18.1).

   4. D. 195a

      The numeric part is right, but the cast applies to a + 1 = 98, which is 'b', not the original 'a'.

   Explanation

   Before the empty string, a + b is NUMERIC: 97 + 98 = 195. After it, concatenation takes over, and (char)(97 + 1) is 'b'. "195" + "b" = "195b". Position relative to the first String decides char arithmetic vs text.

2. Question 2

   What is the output of the following program? ```java public class Main { public static void main(String[] args) { System.out.println((byte) 130); } } ```

   1. A. 130

      130 exceeds byte's maximum of 127, so the explicit cast discards the upper bits rather than preserving the value 130.

   2. B. 127

      This assumes the cast clamps to byte's maximum, but narrowing wraps in two's complement rather than saturating at 127.

   3. C. -126Correct answer

      The explicit narrowing cast discards the upper bits, and 130 wraps two's-complement to 130 - 256 = -126.

   4. D. Compilation fails

      An explicit cast compiles even when the value does not fit the target type, so the code runs and produces output.

   Explanation

   An explicit narrowing cast compiles even when the value doesn't fit (`Compilation fails` is wrong) — the upper bits are simply discarded. byte holds -128..127; 130 wraps two's-complement to 130 - 256 = -126. There is no clamping to 127, so the `127` option is wrong.

3. Question 3

   What is the output of the following program? ```java public class Main { public static void main(String[] args) { int total = 17; System.out.println(total / 5 + " r" + total % 5); } } ```

   1. A. 3.4 r2

      This performs floating-point division; both operands are ints, so / truncates to 3.

   2. B. 3 r0.4

      The division is right, but % yields the integer remainder 2, not a fractional leftover.

   3. C. 4 r2

      Integer division truncates rather than rounding up, so 17 / 5 is 3, not 4.

   4. D. 3 r2Correct answer

      Integer division truncates (17 / 5 = 3) and the remainder operator gives what's left over (17 % 5 = 2), and together they reconstruct 17 (JLS 8 §15.17.2, §15.17.3).

   Explanation

   Integer division truncates: 17 / 5 = 3 (no rounding up — not `4 r2`). The remainder operator gives what's left over: 17 % 5 = 2. Division and remainder together reconstruct the original: 3*5 + 2 = 17.

4. Question 4

   What is the output of the following program? ```java public class Main { public static void main(String[] args) { System.out.println(Integer.MAX_VALUE + 1); } } ```

   1. A. -2147483648Correct answer

      int arithmetic overflows silently by wrapping in two's complement, so MAX_VALUE + 1 wraps around to MIN_VALUE, -2147483648.

   2. B. 2147483648

      This assumes the result is promoted to a wider type, but both operands are int, so the sum stays int and overflows rather than reaching 2147483648.

   3. C. An ArithmeticException is thrown

      Integer overflow is silent in Java; ordinary + never throws ArithmeticException for exceeding the range.

   4. D. Compilation fails

      The expression is valid int arithmetic, so it compiles and runs; the overflow happens at runtime, not compile time.

   Explanation

   Integer arithmetic overflows SILENTLY by wrapping around two's complement — no exception, no error (`An ArithmeticException is thrown`). MAX_VALUE + 1 wraps to MIN_VALUE: -2147483648.

5. Question 5

   What is the result of compiling the following program? ```java public class Main { public static void main(String[] args) { String r = 1 ? "y" : "n"; System.out.println(r); } } ```

   1. A. y

      This applies C-style truthiness where non-zero means true; Java never treats the int 1 as a boolean.

   2. B. n

      This treats the int 1 as false; Java performs no int-to-boolean conversion in either direction.

   3. C. It compiles with a warning

      The mismatch is a hard type error ("incompatible types: int cannot be converted to boolean"), not something the compiler merely warns about.

   4. D. Compilation failsCorrect answer

      A ternary's condition must be a boolean, exactly like if, so the int 1 makes this an incompatible-types error (JLS 8 §15.25).

   Explanation

   A ternary's condition must be a boolean, exactly like if — the int 1 is never treated as true ("incompatible types: int cannot be converted to boolean"). C-style truthiness doesn't exist in Java.

6. Question 6

   What is the output of the following program? ```java public class Main { public static void main(String[] args) { System.out.println(Integer.parseInt("7") + 1 + " " + Integer.valueOf("7").getClass().getSimpleName()); } } ```

   1. A. 71 Integer

      This treats the leading + as concatenation, but both operands are ints appearing before the String, so it is numeric addition giving 8.

   2. B. 8 int

      The arithmetic is right, but valueOf returns the wrapper object, whose simple class name is Integer — getClass() can never report a primitive.

   3. C. 8 IntegerCorrect answer

      parseInt returns the primitive int, so 7 + 1 = 8 numerically, while valueOf returns the wrapper Integer — an object whose simple class name is Integer (JavaDoc 8).

   4. D. 71 int

      Both halves are wrong: the leading + is numeric addition, and the object valueOf produces is an Integer, not a primitive.

   Explanation

   parseInt returns the PRIMITIVE int (7 + 1 = 8, numeric because both sides are ints before the String), while valueOf returns the WRAPPER Integer — an object with a class. That return-type difference is the whole point of having both methods.

7. Question 7

   What is the output of the following program? ```java public class Main { public static void main(String[] args) { Integer a = Integer.valueOf(50); Integer b = Integer.valueOf(50); Integer c = new Integer(50); System.out.println((a == b) + " " + (a == c) + " " + a.equals(c)); } } ```

   1. A. true true true

      This assumes new Integer(50) also comes from the cache, but new always allocates a fresh object, so the reference comparison against it is false.

   2. B. false false true

      This assumes valueOf creates distinct objects, but for 50 it returns the same cached instance, so comparing the two valueOf results is true.

   3. C. true false trueCorrect answer

      valueOf(50) returns the cached Integer for values in -128..127, so the two valueOf references are equal; new Integer bypasses the cache making that reference comparison false, while equals compares the matching value as true.

   4. D. false false false

      This ignores that the two cached references are identical and that equals compares numeric value, which is the same 50 in every case.

   Explanation

   valueOf(50) returns the CACHED Integer for values in -128..127, so a and b are the same object (true). `new Integer(...)` always bypasses the cache and creates a fresh object, so a == c is false — but the values match, so equals is true.

8. Question 8

   Consider the following code fragment inside a method: ```java Pet a = new Pet(); Pet b = new Pet(); b = a; a = null; // line X ``` How many Pet objects are eligible for garbage collection at line X?

   1. A. 0

      This overlooks that the second Pet lost its only reference when b was reassigned to a, so at least one object is already collectible.

   2. B. 1Correct answer

      Reassigning b = a orphans the second Pet (eligible), and setting a = null still leaves the first Pet reachable through b, so exactly one object can be collected.

   3. C. 2

      This assumes both objects become unreachable, but the first Pet is still referenced by b even after a is nulled, so it survives.

   4. D. It cannot be determined

      Reachability here is fully determined by tracking the references, so the count is a definite one, not indeterminate.

   Explanation

   Track the OBJECTS, not the variables. After `b = a;` the second Pet has no references — eligible. After `a = null;` the FIRST Pet is still reachable through b, so it is not eligible. Exactly one object can be collected.