We Keep Coding

Abnormal method overloading result in Java

Could you explain in a detailed manner why the expected result is not correct? As most of the readers expect that the output is Byte Char Int Byte, but of course it is not the correct answer.
public class Tester {
public static String test(byte b) {
return "Byte ";
}
public static String test(char c) {
return "Char ";
}
public static String test(int i) {
return "Int ";
}
public static void main(String[] args) {
byte b = 0;
char c = 'A';
System.out.print(test(true ? b : c));
System.out.print(test(false ? b : c));
System.out.print(test(true ? 0 : 'A'));
System.out.print(test(false ? 'A' : (byte)0));
}
}
The correct result is Int Int Char Int.

This is because overload resolution depends on the compile-time type of the argument expressions, not the runtime type of the argument. See JLS 15.12.2.2:
The argument expression true ? b : c has the type int, so the Int method is called. This is specified in the JLS 15.25.2, where it is said that if none of the special cases match (none of them do here), then the type of the conditional expression is the type after applying numeric promotion to the second and third operands:
An expression appears in a numeric choice context if the expression is one of the following:
The second or third operand of a numeric conditional expression
[...]
Numeric promotion determines the promoted type of all the expressions in a numeric context. [...] The rules are as follows:
[...] (none of these rules match in the case of a short and a byte expression)
Otherwise, none of the expressions are of type double, float, or long. In this case, the kind of context determines how the promoted type is chosen.
In a numeric choice context, the following rules apply:
[...] (none of these rules match in the case of a short and a byte expression)
Otherwise, the promoted type is int, and all the expressions that are not of type int undergo widening primitive conversion to int.
This is why true ? b : c is of type int. The same goes for false ? b : c and false ? 'A' : (byte)0. It doesn't matter what the condition is. The type of the expression is determined by the types of the second and third operands.
As for test(true ? 0 : 'A'), this can be explained by a rule that I omitted above, just before the last "Otherwise..."
Otherwise, if any expression is of type char, and every other expression is either of type char or a constant expression of type int with a value that is representable in the type char, then the promoted type is char, and the int expressions undergo narrowing primitive conversion to char.
In this case, the expression "0" is a "a constant expression of type int with a value that is representable in the type char".
One way to think about the type of a conditional expression, is that it's the smallest type that the expressions of both of the branches can "fit". For a byte b and a char c, int is the smallest type that can fit both of them. For 0, and 'A', char is enough to fit both, as it is known that 0 is in the range of char.

For the type of a conditional expression in Java, always consult the JLS charts (Section 15.25).
3rd →
byte
short
char
int
2nd ↓
 
 
 
 
byte
byte
short
bnp(byte,char)
byte | bnp(byte,int)
Byte
byte
short
bnp(Byte,char)
byte | bnp(Byte,int)
short
short
short
bnp(short,char)
short | bnp(short,int)
Short
short
short
bnp(Short,char)
short | bnp(Short,int)
char
bnp(char,byte)
bnp(char,short)
char
char | bnp(char,int)
where the notation "bnp(x, y)" means the type that is the result of binary numeric promotion of x and y, and the form "T | bnp(..)" means that if one operand is a constant expression of type int and may be representable in type T, then binary numeric promotion is used if the operand is not representable in type T.
For the first 2 calls, we have a char and a byte, so the result is "bnp(byte, char)", or the type int.
For the third call, we have a constant expression of type int and a char, and the value is representable as a char (it's 0), so the result is the type char.
For the fourth call, we have a byte and a char, so we back to "bnp(byte,char)", which is the type int.

The ternary operator converts its expressions to a common type in order for a variable to store its result.
Imagine if you had an expression like this:
char v = <myCondition> ? 'a' : 0L;
The previous statement would make sense only if the condition was true, but what about if this was false and 0L was to be returned? long and char are not the same data type. So, the compiler needs to find a common type, without losing precision, in order to allow both expressions to be returned and assigned to a variable suitable for both of them. The resulting data type is picked up regardless the condition's outcome.
In this case, long cannot be cast to int and then char as it would lose precision whereas char could be cast to int and then promoted to long. This is why the previous statement can be correctly written like so:
long v = <myCondition> ? 'a' : 0L;
In your example, the first ternary operator has a byte and a char, a byte can be promoted to an int while a char can be cast to an int. The other way around, where a char would be cast to a byte is not possible as this would cause a precision loss (a char occupies two bytes). By applying the same logic of promotion, you can also explain the remaining cases. Except for the third one, where you should apply the resolving table from the previously provided link to the documentation.

Table 15.25-A in the Java language specification describes what type the result of a ?: operator is, depending on the contributing types.
Your first example involves byte and char, so the result is a bnp (binary numeric promotion) of these, and for anything but double, float, or long, the resulting type is int.
Same thing for the others.

Java Compiler preferring `int` type even if short and bytes are possible [duplicate]

If I write something like this
System.out.println(18);
Which type has the '18'?
Is it int or byte?
Or doesn't it have a type yet?
It can't be int, because something like this is correct:
byte b = 3;
And this is incorrect:
int i = 3;
byte bb = i; //error!
EDIT:
I think I found the right part in the spec at Assignment Conversion :
The compile-time narrowing of constants means that code such as:
byte theAnswer = 42;
is allowed. Without the narrowing, the fact that the integer literal 42 has type int would mean that a cast to byte would be required:
byte theAnswer = (byte) 42; // cast is permitted but not required

This
18
is known as an integer literal. There are all sorts of literals, floating point, String, character, etc.
In the following,
byte b = 3;
the literal 3 is an integer literal. It's also a constant expression. And since Java can tell that 3 fits in a byte, it can safely apply a narrowing primitive conversion and store the result in a byte variable.
In this
int i = 3;
byte bb = i; //error!
the literal 3 is a constant expression, but the variable i is not. The compiler simply decides that i is not a constant expression and therefore doesn't go out of its way to figure out its value, a conversion to byte may lose information (how to convert 12345 to a byte?) and should therefore not be allowed. You can override this behavior by making i a constant variable
final int i = 3;
byte bb = i; // no error!
or by specifying an explicit cast
int i = 3;
byte bb = (byte) i; // no error!

The JLS-4.2.1 - Integral Types and Values
The values of the integral types are integers in the following ranges:
For byte, from -128 to 127, inclusive
For short, from -32768 to 32767, inclusive
For int, from -2147483648 to 2147483647, inclusive
For long, from -9223372036854775808 to 9223372036854775807, inclusive
For char, from '\u0000' to '\uffff' inclusive, that is, from 0 to 65535
And JLS-3.10.1 - Integer Literals
An integer literal is of type long if it is suffixed with an ASCII letter L or l (ell); otherwise it is of type int (§4.2.1).
Finally, JLS-3.10.2 - Floating-Point Literals includes
A floating-point literal is of type float if it is suffixed with an ASCII letter F or f; otherwise its type is double and it can optionally be suffixed with an ASCII letter D or d (§4.2.3).
As for byte b = 3; it is a Narrowing Conversion from int to byte.

As stated by others, it's an integer literal.
Under the hood, it appears Java was written for 32 bit processors.
An integer is between +/- ~2.147 million, which is 2^31 with a signage bit.
So whether you're writing a bit or a full int, it's a single processor function, therefore a single memory allocation.

Widening primitive conversions followed by boxing conversions [duplicate]

final byte b = 12;
Short s = b;
Integer i = b;
Program compiles fine for Short but for Integer compilation fails with "incompatible types" message.
I am having difficult time trying to understand this behavior. I could not find anything for this specific scenario..

I attempted to duplicate this with a wider group of assignment contexts:
final byte b = 12;
Byte b2 = b;
Character c = b; // Only an error if b isn't final
char c2 = b; // Only an error if b isn't final
Short s = b; // Only an error if b isn't final
short s2 = b;
Integer i = b; // Error, as indicated in the question
int i2 = b;
Long l = b; // Also an error
long l2 = b;
Float f = b; // Also an error
float f2 = b;
Double d = b; // Also an error
double d2 = b;
Assigning not just to a Integer, but also to a Float, a Long or a Double is also an error.
Interestingly, if the original declaration of b was NOT final, then assigning to a Character, a char, or a Short fails also.
Section 5.2 of the JLS sheds a little light on the subject of assignment contexts and their allowed conversions.
Assignment contexts allow the use of one of the following:
an identity conversion (§5.1.1)
a widening primitive conversion (§5.1.2)
a widening reference conversion (§5.1.5)
a boxing conversion (§5.1.7) optionally followed by a widening reference conversion
an unboxing conversion (§5.1.8) optionally followed by a widening primitive conversion.
This covers all of the conversions to wider primitive variables, which are always allowed, whether b is final or not. (That holds unless b is negative, in which case the assignment to an unsigned char (or Character) would fail.) Continuing:
In addition, if the expression is a constant expression (§15.28) of type byte, short, char, or int:
A narrowing primitive conversion may be used if the type of the variable is byte, short, or char, and the value of the constant expression is representable in the type of the variable.
A narrowing primitive conversion followed by a boxing conversion may be used if the type of the variable is:
Byte and the value of the constant expression is representable in the type byte.
Short and the value of the constant expression is representable in the type short.
Character and the value of the constant expression is representable in the type char.
Because b is final, the expression b is a constant expression, allowing it to be narrowed from the int constant expression 12 to byte, char, or short and then boxed to Byte, Character, or Short, but strangely, not to Integer or anything "above". The only possible explanation I can think of is that constant expressions that are subject to a primitive narrowing conversion aren't specifically allowed to be converted to Integer, Long, Float, or Double.
If b isn't final, then the narrowing followed by boxing isn't allowed, and a non-constant expression can't be promoted from byte to char either.

Implicit conversion in wrapper class

I have confusion in Number Wrapper Class in Java.
These two assignments look symmetric - a char is assigned to Integer, and an int is assigned to Character. However, the first assignment
Integer i = 'a';
gives Compilation Error, while the second assignment
Character ch2 = 97;
is allowed. Why?

Although int i = 'a' works fine, converting the same to Integer is not allowed, because it requires a boxing conversion.
Java's boxing conversion is defined only for eight cases:
From type boolean to type Boolean
From type byte to type Byte
From type short to type Short
From type char to type Character
From type int to type Integer
From type long to type Long
From type float to type Float
From type double to type Double
Since 'a' is a char literal, Java does not allow conversion from char to Integer: a character literal is always of type char.
However, when you write
Character ch2 = 97;
Java compiler sees that 97 is in the valid range for char (i.e. 0..65535), so it treats 97 as char, not int, and allows the boxing conversion. Trying the same with an out-of-range constant produces an error:
Character ch3 = 65536; // error: incompatible types: int cannot be converted to Character

The rules for boxing conversions can be found in the Java Language Spec, chapter 5.1.7
Boxing conversion converts expressions of primitive type to corresponding expressions of reference type. Specifically, the following nine conversions are called the boxing conversions:
... followed by a list of valid conversions from primitive types to reference types.
The point is: in any case, a conversion must take place.
If you had
int a = '97'
that is fine; as that is a widening conversion (sectin 5.12 in the JLS). But that case
Integer i = '97'
isn't listed as "valid" conversion for Auto-boxing. In other words: the JLS doesn't allow for it; and this the compiler doesn't do it either.
...

Integer i = 'a' just wraps int i ='a'. Since 'a' is not an int it throws an error.
Likewise, Character ch2 = 97 wraps char ch2 = 97. However, 97 is an valid char! It represents the character "a". Example:
System.out.println((char) 97); //Output: a

This is because when setting a character to an integer it's returning the ASCII code number which is a primitive int.

Integer arithmetic in Java with char and integer literal

Can someone explain to me why the following code compiles OK in Java?
char c = 'a' + 10;
Why is this not equivalent to the following, which does not compile?
int i = 10;
char c = 'a' + i;
The Java Language Specification (section 3.10.1) states "An integer literal is of type long if it is suffixed with an ASCII letter L or l (ell); otherwise it is of type int (§4.2.1)." Section 4.2.2 refers to "The numerical operators, which result in a value of type int or long." So the result of the addition should, in my understanding, be an int, which cannot be assigned to the char variable c.
However, it compiles fine (at least in Sun JDK 1.6.0 release 17 and in Eclipse Helios).
Rather an artificial example perhaps, but it is used in an introductory Java course I have been teaching, and it now occurs to me that I don't really understand why it works.

It is because the compiler can check that it ('a' + 10) is within the bounds of a char whereas it cannot (in general) check that 'a' + <an integer> is within the bounds.

'a' + 10 is a compile-time constant expression with the value of 'k', which can initialise a variable of type char. This is the same as being able to assign a byte variable with a literal integer in [-128, 127]. A byte in the range of [128, 255] may be more annoying.

char is actually an unsigned 16-bit integer with a range 0-65535. So you can assign any integer literal in that range to a char, e.g., "char c = 96", which results in "c" holding the character "a". You can print out the result using System.out.println(c).
For the constant expression on the right-hand-side of "char c = 'a' + 10", 'a' is promoted to int first because of the Java numeric promotion rules and the integer value is 96. After adding 10 to it, we get a literal integer 106, which can be assigned to a char.
The right-hand-side of "char c = 'a' + i" is not a constant expression and the expression result assignment rule requires an explicit cast from int to char, i.e., "char c = (char) ('a' + i)".

This code should works:
int i = 10;
char x = (char)('a' + i);

The constant is of a different type (I know the spec says that 10 should be an int, but the compiler doesn't see it that way).
In char c = 'a' + 10, 10 is actually considered a constant variable of type char (so it can be added to a). Therefore char c = char + char works.
In int i = 10;
char c = 'a' + i; You are adding a char to an integer (an integer can be much bigger than a char, so it chooses the bigger data type [int] to be the result a.k.a: 'a' + i = int + int). So the result of the addition is an integer, which cannot fit into the char c.
If you explicitly casted i to be a char (e.g.: char c = 'a' + (char)i;) it could work or if you did the opposite (e.g.: int c = (int)'a' + i;) it would work.

According to Java specification as of 2020 for widening and narrowing conversions of integral values in expressions:
"In a numeric arithmetic context ... the promoted type is int,
and any expressions that are not of type int undergo widening
primitive conversion to int"
In assignment context:
"...if the expression is a constant expression of type byte, short,
char, or int:
• A narrowing primitive conversion may be used if the
variable is of type byte, short, or char, and the value of the
constant expression is representable in the type of the variable."
So, in char c = 'a' + 10; the left constant value is a charand the right constant value is int fitting into a char. While there is an assignment and int 10 fits into char, int gets converted to char. And the overall result of addition is char.
And in char c = 'a' + i; (where int i = 10;) the i is not constant, so, notwithstanding the assignment, the char 'a' is promoted to int and the overall result is int. Thus, the assignment is erroneous without an explicit typecast.
Note, that the following original answer is wrong (it cites treatment in numeric choice contexts, like in switch statement):
According to Java specification for widening and narrowing conversions in expressions:
If any expression is of type int and is not a constant expression,
then the promoted type is int, and other expressions that are not of
type int undergo widening primitive conversion to int.
...
if any expression is of type char, and every other expression is
either of type 'char' or a constant expression of type 'int' with a
value that is representable in the type 'char', then the promoted type
is char, and the int expressions undergo narrowing primitive
conversion to char.
So, in char c = 'a' + 10; the left expression is a char and the right constant expression is int fitting into a char. So, the constant gets converted to char. And the overall result is char.
And in char c = 'a' + i; (where int i = 10;) the right expression is not constant, so the the char 'a' is promoted to int and the overall result is int.