Which Overload Runs for the Binary Literal 0B1010_1010_0101_1001_0110?
Given: What is the result? - 
Community Votes
100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
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.
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.
Community Discussion (3 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
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
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.