Which Overload Runs for the Binary Literal 0B1010_1010_0101_1001_0110?
Short answer
C The int overload runs because the binary literal has no L suffix and its 20-bit value fits an int, printing one.
Question
Key Takeaways
What is tested is numeric-literal typing driving overload resolution: a binary literal with no L suffix is an int, so the int method runs — the trap is expecting the long overload or a runtime exception.
A binary literal such as 0B1010_1010_0101_1001_0110 with underscores but no L suffix is typed as an int, so a call to an overloaded method binds to the int version. This page shows why the program prints one (C) and why neither a compile error nor a NumberFormatException occurs.
Common mistake: The most common wrong pick is B ("two") because the 20-bit literal looks like it needs a long; without an L suffix the literal is an int, so the int overload is chosen and no widening to long occurs.
Expert Analysis
Why the Answer Is Correct
The argument 0B1010_1010_0101_1001_0110 uses the binary prefix 0B with underscores between digits but carries no L or l suffix, so per JLS 3.10.1 it is an int literal. Its value, 0xAA596 (697,750 in decimal), is a 20-bit number that fits comfortably in a 32-bit int, so compilation succeeds. Overload resolution happens at compile time using the declared type of the argument, and an exact int match is preferred over widening the value to long. The method whose parameter is int therefore executes and prints one, which is option C.
Why the Other Options Are Wrong
B ("two") would require the argument to be typed long, which only happens if the literal ended with L or if no int-accepting overload existed. A ("compilation fails") is incorrect because underscores are legal between the digits of a numeric literal and the 20-bit value is well within int range. D is wrong because NumberFormatException is a runtime exception thrown when parsing text (for example Integer.parseInt("1010")), not when the compiler reads a numeric literal in source code. None of these outcomes can occur with this code.
Community Comment Notes
d7bb0b2 states the key rule twice: the literal without a suffix "is an int in binary", while the same digits with an L suffix would be a long, and since it fits an int the "int method is called". ASPushkin simply remarks it is "same as 199", flagging a duplicate question elsewhere in the 1Z0-819 pool. No commenter argues for a compile error or a NumberFormatException, which is consistent with the unanimous vote share for C. The community reasoning aligns exactly with the JLS literal-typing rule.
Official Reference
- https://docs.oracle.com/javase/specs/jls/se17/html/jls-3.html#jls-3.10.1
- https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
These links open the official vendor documentation in a new tab.
Exam Strategy
Scan numeric literals for an L/l suffix before reading anything else: no suffix means int, and the compiler picks the closest matching overload without widening. Underscores placed between digits confirm the code compiles, letting you eliminate 'compilation fails' immediately.
Community Votes
100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 3 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 3
-
d7bb0b2 👍 1 Answered C0B1010_1010_0101_1001_0110 is an int in binary 0B1010_1010_0101_1001_0110L is a long binary
-
d7bb0b2 👍 1 Answered C0B1010_1010_0101_1001_0110 => is a 11111110 So fit int then int method is called
-
ASPushkin 👍 1same as 199
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.