Why int type method is allowing character type as return value?

Question

Here is my code but I am not getting how int getValue() method accepting char type as return value. How is it working? could any body please explain me how this method is working?

public class CharToInteger {
    private static Scanner input;
    public static int getValue(char character){
        return character;       
    }

    public static void main(String[] args) {
        input = new Scanner(System.in);
        System.out.println("Enter a character to get value of it:");
        String inputString=(String) input.next();
        char inputCharacter=inputString.charAt(0);
        System.out.println(getValue(inputCharacter));
    }

}

Thanks in advance :)

Answer 1

OK, so first things first:

This is a widening primitive type conversion, so this is legal. You can:

int foo() { return 'a' /* character constant */ };
long foo() { return 3; /* int constant */ }

But you CANNOT DO:

char foo() { return 1; /* int constant */ }
int foo() { return 1L; /* long constant */ }

Second: what it returns is NOT THE ASCII CODE AT ALL. Java does Unicode.

It just happens that when Java was created, Unicode only defined code points fitting 16 bits; hence char was created as a 2 byte, unsigned primitive type (it is the only unsigned primitive type in Java) matching the then-called UCS-2 character coding (a 1 to 1 mapping between the coding and code points).

However, afterwards Unicode went "wide" and code points outside the BMP (ie, greater than U+FFFF) appeared; since then UCS-2 became UTF-16, and code points outside the BMP require two chars for one code point (a leading surrogate and a trailing surrogate; in previous Unicode versions, and in the Java API, those were called resp. high and low surrogate). A char is therefore now a UTF-16 code unit.

It is still true, however, that for code points in the BMP, the char value exactly matches the code point.

---

Now, in order to "fix" your program to accurately display the "character value", ie the code point, for each possible entry, you would do that (Java 8):

public static void main(String[] args) {
    final Scanner input = new Scanner(System.in);
    System.out.println("Enter a character to get value of it:");
    String inputString =  input.next();
    // Print -1 on an empty input
    final OptionalInt codepoint = inputString.codePoints().findFirst();
    System.out.println(codepoint.isPresent() ? codepoint.get() : -1);
}

This will also handle code points outside the BMP.

Answer 2

public static int getValue(char character){
    return character;//<-- unicode value is being returned, e.g. char 0 -> int 48
    // char ranges from 0 - 65535
}

From JSL:

5.1.4. Widening and Narrowing Primitive Conversion

The following conversion combines both widening and narrowing primitive conversions:

byte to char

First, the byte is converted to an int via widening primitive conversion (§5.1.2), and then the resulting int is converted to a char by narrowing primitive conversion (§5.1.3).

see more:

Answer 3

This is because char in java is 2 bytes and int is 4 bytes. So it is a widening conversion, which happens implicitly in Java. The return value is the ASCII value on the input character.

Answer 4

char is effectively an unsigned 16-bit integer type in Java.

Like other integer types, you can perform an assignment conversion from an integer constant to any integer type so long as it's in the appropriate range.

And it is legal to ,

public static int getValue(char character){
    return character;       
}

Answer 5

Char is UTF-16 code representation - read it as 2-byte integral value. int is 4-byte integral value. Java can implicitly cast smaller sized integrals to larger ones - char to int, int to long, because conversion this way doesn't lead to precision or data loss.

The vice versa way doesn't work - you cannot implicitly convert int to char and long to int, because int has a much wider range of possible values than char.

Answer 6

Put simply, Java is willing to implicitly convert a char to an int. It will convert it to a 16-bit Unicode value. If the input were 'A' you will get '65' as your output.

It's arguable (by me!) that characters and integers are sufficiently different that the language shouldn't be so sloppy as from time to time it can lead to surprise behaviour.

If you want chapter and verse look at Sec 5.1.2 here:

https://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html