We Keep Coding

Java Program on character Array [duplicate]

When adding 'a' + 'b' it produces 195. Is the output datatype char or int?

The result of adding Java chars, shorts, or bytes is an int:
Java Language Specification on Binary Numeric Promotion:
If any of the operands is of a reference type, unboxing conversion
(§5.1.8) is performed. Then:
If either operand is of type double, the
other is converted to double.
Otherwise, if either operand is of type
float, the other is converted to float.
Otherwise, if either operand
is of type long, the other is converted to long.
Otherwise, both
operands are converted to type int.
But note what it says about compound assignment operators (like +=):
The result of the binary operation is converted to the type of the left-hand variable ... and the result of the conversion is stored into the variable.
For example:
char x = 1, y = 2;
x = x + y; // compile error: "possible loss of precision (found int, required char)"
x = (char)(x + y); // explicit cast back to char; OK
x += y; // compound operation-assignment; also OK
One way you can find out the type of the result, in general, is to cast it to an Object and ask it what class it is:
System.out.println(((Object)('a' + 'b')).getClass());
// outputs: class java.lang.Integer
If you're interested in performance, note that the Java bytecode doesn't even have dedicated instructions for arithmetic with the smaller data types. For example, for adding, there are instructions iadd (for ints), ladd (for longs), fadd (for floats), dadd (for doubles), and that's it. To simulate x += y with the smaller types, the compiler will use iadd and then zero the upper bytes of the int using an instruction like i2c ("int to char"). If the native CPU has dedicated instructions for 1-byte or 2-byte data, it's up to the Java virtual machine to optimize for that at run time.
If you want to concatenate characters as a String rather than interpreting them as a numeric type, there are lots of ways to do that. The easiest is adding an empty String to the expression, because adding a char and a String results in a String. All of these expressions result in the String "ab":
'a' + "" + 'b'
"" + 'a' + 'b' (this works because "" + 'a' is evaluated first; if the "" were at the end instead you would get "195")
new String(new char[] { 'a', 'b' })
new StringBuilder().append('a').append('b').toString()
String.format("%c%c", 'a', 'b')

Binary arithmetic operations on char and byte (and short) promote to int -- JLS 5.6.2.

You may wish to learn the following expressions about char.
char c='A';
int i=c+1;
System.out.println("i = "+i);
This is perfectly valid in Java and returns 66, the corresponding value of the character (Unicode) of c+1.
String temp="";
temp+=c;
System.out.println("temp = "+temp);
This is too valid in Java and the String type variable temp automatically accepts c of type char and produces temp=A on the console.
All the following statements are also valid in Java!
Integer intType=new Integer(c);
System.out.println("intType = "+intType);
Double doubleType=new Double(c);
System.out.println("doubleType = "+doubleType);
Float floatType=new Float(c);
System.out.println("floatType = "+floatType);
BigDecimal decimalType=new BigDecimal(c);
System.out.println("decimalType = "+decimalType);
Long longType=new Long(c);
System.out.println("longType = "+longType);
Although c is a type of char, it can be supplied with no error in the respective constructors and all of the above statements are treated as valid statements. They produce the following outputs respectively.
intType = 65
doubleType = 65.0
floatType = 65.0
decimalType = 65
longType =65
char is a primitive numeric integral type and as such is subject to all the rules of these beasts including conversions and promotions. You'll want to read up on this, and the JLS is one of the best sources for this: Conversions and Promotions. In particular, read the short bit on "5.1.2 Widening Primitive Conversion".

The Java compiler can interpret it as either one.
Check it by writing a program and looking for compiler errors:
public static void main(String[] args) {
int result1 = 'a' + 'b';
char result2 = 'a' + 'b';
}
If it's a char, then the first line will give me an error and the second one will not.
If it's an int, then the opposite will happen.
I compiled it and I got..... NO ERRORS. So Java accepts both.
However, when I printed them, I got:
int: 195
char: Ã
What happens is that when you do:
char result2 = 'a' + 'b'
an implicit conversion is performed (a "primitive narrowing conversion" from int to char).

According to the binary promotion rules, if neither of the operands is double, float or long, both are promoted to int. However, I strongly advice against treating char type as numeric, that kind of defeats its purpose.

While you have the correct answer already (referenced in the JLS), here's a bit of code to verify that you get an int when adding two chars.
public class CharAdditionTest
{
public static void main(String args[])
{
char a = 'a';
char b = 'b';
Object obj = a + b;
System.out.println(obj.getClass().getName());
}
}
The output is
java.lang.Integer

char is represented as Unicode values and where Unicode values are represented by \u followed by Hexadecimal values.
As any arithmetic operation on char values promoted to int , so the result of 'a' + 'b' is calculated as
1.) Apply the Unicode values on corresponding char using Unicode Table
2.) Apply the Hexadecimal to Decimal conversion and then perform the operation on Decimal values.
char Unicode Decimal
a 0061 97
b 0062 98 +
195
Unicode To Decimal Converter
Example
0061
(0*163) + (0*162) + (6*161) +
(1*160)
(0*4096) + (0*256) + (6*16) + (1*1)
0 + 0 + 96 + 1 = 97
0062
(0*163) + (0*162) + (6*161) +
(2*160)
(0*4096) + (0*256) + (6*16) + (2*1)
0 + 0 + 96 + 2 = 98
Hence 97 + 98 = 195
Example 2
char Unicode Decimal
Ջ 054b 1355
À 00c0 192
--------
1547 +
1163 -
7 /
260160 *
11 %

While Boann's answer is correct, there is a complication that applies to the case of constant expressions when they appear in assignment contexts.
Consider the following examples:
char x = 'a' + 'b'; // OK
char y = 'a';
char z = y + 'b'; // Compilation error
What is going on? They mean the same thing don't they? And why is it legal to assign an int to a char in the first example?
When a constant expression appears in an assignment context, the Java compiler computes the value of the expression and sees if it is in the range of the type that you are assigning to. If it is, then an implicit narrowing primitive conversion is applied.
In the first example, 'a' + 'b' is a constant expression, and its
value will fit in a char, so the compiler allows the implicit narrowing of the int expression result to a char.
In the second example, y is a variable so y + 'b' is NOT a
constant expression. So even though Blind Freddy can see that the
value will fit, the compiler does NOT allow any implicit narrowing, and you get a compilation error saying that an int cannot be assigned to a char.
There are some other caveats on when an implicit narrowing primitive conversion is allowed in this context; see JLS 5.2 and JLS 15.28 for the full details.
The latter explains in detail the requirements for a constant expression. It may not be what you may think. (For example, just declaring y as final doesn't help.)

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.

Promotion of primitive types

I have a question about the promotion of primitive types in Java. As we can see in the following example, one of the methods does not compile due to an error of type mismatch. Each method returns the same value but in different types.
The version of primitive long method works without error while the version of wrapper class Long fails. This is because the int literal in the return statement will be first promoted to a broader primitive type (e.g. long) and then to the corresponding wrapper class Integer and so on. Since Integer is not a subclass of Long the compiler gives an error.
But why does the version of wrapper class Byte works without any error? What exactly does the compiler do at this point?
long getPrimitiveLong() {
return 12; // valid
}
Long getWrapperLong() {
return 12; // Error: type mismatch
}
Byte getWrapperByte() {
return 12; // valid
}

The version with Byte works through some compiler magic.
Unlike long numeric literals which can be constructed with a L suffix, e.g. 12L, there is no such thing as a byte literal. That is why Java compiler treats numeric literals that fit in a byte as byte literals. Hence, 12 in your last example is considered a constant of type byte.
Java Language Specification offers a description of this conversion in section 5.2:
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.

This is because Java allows 1 conversion or Autoboxing, not more.
Java can do all these:
int i = 5;
double d = i; // int to double
long l = i; // int to long
long l = d; // double to long
Or autobox:
Integer i = 5; // int to Integer
Double d = 5.0; // double to Double
Long l = 5L; // long to Long
Converting twice, say int to Double, gives Java a hard time.

number like 12 consider as int by default by the compiler that is why the error
To fix that you can use casting for byte and place L after the value of long variable.
Read following post for more details
http://javaseeeedu.blogspot.com/2015/12/casting-part-1.html

As a short answer - try to replace 12 with 128 (byte is in range -128 to 127).
It won't compile, right?
The outcome here is that the compiler knows about byte boundaries.
For the in-depth answer you can do a deep dive into OpenJDK.

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.

In Java, is the result of the addition of two chars an int or a char?

When adding 'a' + 'b' it produces 195. Is the output datatype char or int?

The result of adding Java chars, shorts, or bytes is an int:
Java Language Specification on Binary Numeric Promotion:
If any of the operands is of a reference type, unboxing conversion
(§5.1.8) is performed. Then:
If either operand is of type double, the
other is converted to double.
Otherwise, if either operand is of type
float, the other is converted to float.
Otherwise, if either operand
is of type long, the other is converted to long.
Otherwise, both
operands are converted to type int.
But note what it says about compound assignment operators (like +=):
The result of the binary operation is converted to the type of the left-hand variable ... and the result of the conversion is stored into the variable.
For example:
char x = 1, y = 2;
x = x + y; // compile error: "possible loss of precision (found int, required char)"
x = (char)(x + y); // explicit cast back to char; OK
x += y; // compound operation-assignment; also OK
One way you can find out the type of the result, in general, is to cast it to an Object and ask it what class it is:
System.out.println(((Object)('a' + 'b')).getClass());
// outputs: class java.lang.Integer
If you're interested in performance, note that the Java bytecode doesn't even have dedicated instructions for arithmetic with the smaller data types. For example, for adding, there are instructions iadd (for ints), ladd (for longs), fadd (for floats), dadd (for doubles), and that's it. To simulate x += y with the smaller types, the compiler will use iadd and then zero the upper bytes of the int using an instruction like i2c ("int to char"). If the native CPU has dedicated instructions for 1-byte or 2-byte data, it's up to the Java virtual machine to optimize for that at run time.
If you want to concatenate characters as a String rather than interpreting them as a numeric type, there are lots of ways to do that. The easiest is adding an empty String to the expression, because adding a char and a String results in a String. All of these expressions result in the String "ab":
'a' + "" + 'b'
"" + 'a' + 'b' (this works because "" + 'a' is evaluated first; if the "" were at the end instead you would get "195")
new String(new char[] { 'a', 'b' })
new StringBuilder().append('a').append('b').toString()
String.format("%c%c", 'a', 'b')

Binary arithmetic operations on char and byte (and short) promote to int -- JLS 5.6.2.

You may wish to learn the following expressions about char.
char c='A';
int i=c+1;
System.out.println("i = "+i);
This is perfectly valid in Java and returns 66, the corresponding value of the character (Unicode) of c+1.
String temp="";
temp+=c;
System.out.println("temp = "+temp);
This is too valid in Java and the String type variable temp automatically accepts c of type char and produces temp=A on the console.
All the following statements are also valid in Java!
Integer intType=new Integer(c);
System.out.println("intType = "+intType);
Double doubleType=new Double(c);
System.out.println("doubleType = "+doubleType);
Float floatType=new Float(c);
System.out.println("floatType = "+floatType);
BigDecimal decimalType=new BigDecimal(c);
System.out.println("decimalType = "+decimalType);
Long longType=new Long(c);
System.out.println("longType = "+longType);
Although c is a type of char, it can be supplied with no error in the respective constructors and all of the above statements are treated as valid statements. They produce the following outputs respectively.
intType = 65
doubleType = 65.0
floatType = 65.0
decimalType = 65
longType =65
char is a primitive numeric integral type and as such is subject to all the rules of these beasts including conversions and promotions. You'll want to read up on this, and the JLS is one of the best sources for this: Conversions and Promotions. In particular, read the short bit on "5.1.2 Widening Primitive Conversion".

The Java compiler can interpret it as either one.
Check it by writing a program and looking for compiler errors:
public static void main(String[] args) {
int result1 = 'a' + 'b';
char result2 = 'a' + 'b';
}
If it's a char, then the first line will give me an error and the second one will not.
If it's an int, then the opposite will happen.
I compiled it and I got..... NO ERRORS. So Java accepts both.
However, when I printed them, I got:
int: 195
char: Ã
What happens is that when you do:
char result2 = 'a' + 'b'
an implicit conversion is performed (a "primitive narrowing conversion" from int to char).

According to the binary promotion rules, if neither of the operands is double, float or long, both are promoted to int. However, I strongly advice against treating char type as numeric, that kind of defeats its purpose.

While you have the correct answer already (referenced in the JLS), here's a bit of code to verify that you get an int when adding two chars.
public class CharAdditionTest
{
public static void main(String args[])
{
char a = 'a';
char b = 'b';
Object obj = a + b;
System.out.println(obj.getClass().getName());
}
}
The output is
java.lang.Integer

char is represented as Unicode values and where Unicode values are represented by \u followed by Hexadecimal values.
As any arithmetic operation on char values promoted to int , so the result of 'a' + 'b' is calculated as
1.) Apply the Unicode values on corresponding char using Unicode Table
2.) Apply the Hexadecimal to Decimal conversion and then perform the operation on Decimal values.
char Unicode Decimal
a 0061 97
b 0062 98 +
195
Unicode To Decimal Converter
Example
0061
(0*163) + (0*162) + (6*161) +
(1*160)
(0*4096) + (0*256) + (6*16) + (1*1)
0 + 0 + 96 + 1 = 97
0062
(0*163) + (0*162) + (6*161) +
(2*160)
(0*4096) + (0*256) + (6*16) + (2*1)
0 + 0 + 96 + 2 = 98
Hence 97 + 98 = 195
Example 2
char Unicode Decimal
Ջ 054b 1355
À 00c0 192
--------
1547 +
1163 -
7 /
260160 *
11 %

While Boann's answer is correct, there is a complication that applies to the case of constant expressions when they appear in assignment contexts.
Consider the following examples:
char x = 'a' + 'b'; // OK
char y = 'a';
char z = y + 'b'; // Compilation error
What is going on? They mean the same thing don't they? And why is it legal to assign an int to a char in the first example?
When a constant expression appears in an assignment context, the Java compiler computes the value of the expression and sees if it is in the range of the type that you are assigning to. If it is, then an implicit narrowing primitive conversion is applied.
In the first example, 'a' + 'b' is a constant expression, and its
value will fit in a char, so the compiler allows the implicit narrowing of the int expression result to a char.
In the second example, y is a variable so y + 'b' is NOT a
constant expression. So even though Blind Freddy can see that the
value will fit, the compiler does NOT allow any implicit narrowing, and you get a compilation error saying that an int cannot be assigned to a char.
There are some other caveats on when an implicit narrowing primitive conversion is allowed in this context; see JLS 5.2 and JLS 15.28 for the full details.
The latter explains in detail the requirements for a constant expression. It may not be what you may think. (For example, just declaring y as final doesn't help.)