Okay, everyone's been running all over the place with this one,
dragging in all sorts of irrelevant stuff like Oriental languages.
Let's nail this puppy down.
First, I'm going to ignore the title ('A'++ == 'B': Always True?)
because as Vincent and Gordon noted, it has two silly typos. Let's talk
about the example code instead.
First, the character constant 'A' will *always* result in the char
value of \u0041. This is defined by chapter 3 of the Java Language
Specification (second edition) and by the nature of Unicode. Anyone who
thinks that Oriental languages matter doesn't understand the whole
point of Unicode: it combines ALL language 'glyphs' into a single
unambiguous numbering system. Unicode values \0000-\007F always
represent ASCII codes 0-127, okay?
So, after the initial assignment ltr='A' we know that the value in ltr
is 0x0041. Guaranteed, because 'A' is a character constant.
Then after the increment ltr++, we know that the value in ltr is
0x0042, by the rules of 16-bit unsigned arithmetic. This we know
corresponds to the value of 'B', because 'B' is also a character
constant.
But! We cannot say absolutely for sure what will be printed. The
System.out.println results in a conversion from the 16-bit Unicode
value in the char to 8-bit byte(s). This conversion is performed "using
the default character encoding." MOst of the time this is a theoretical
issue; you'll usually be using a character encoding that translates
0x0000-0x007F into byte values 0x00-0x7F. A counter-example would be if
you were running on an IBM mainframe, and the default character
encoding for the JVM is something like ebcdic-us; in that case the
output byte values would be EBCDIC (e.g. outputting 0x0041 would result
in 0xC1, which is an EBCDIC 'A').
Then there is the question of how those byte values will be interpreted
by your display (or print) device. Again, this is primarily a
theoretical issue, as most display and print devices map byte values
0x00-0x7F into the appropriate ASCII glyphs. Again, one counter-example
is that IBM mainframes terminals and printers will be expecting EBCDIC
codes.
So: the computation is defined to do what you expect. It will produce
the exact same output as System.out.println("A\nB"), whatever that
output might actually look like.
Now for the question that you didn't ask. If you're working with
characters that you read in, rather than 'X' constants that you coded
into your program, then you have another character-set conversion to
worry about. The basic rules are the same as for the output: in most
cases you'll have a direct conversion from the ASCII range 0x00-0x7F
into 0x0000-0x007F. But there could be unusual cases such as EBCDIC. In
general, these unusual cases will be automagically handled by "the
default character encoding" for your JVM and environment.
There are two main places that you can run into grief:
1) the default character encoding turns out not to be appropriate, or
2) you try to read/write binary data through the character encoder.
In summary: character constants coded into your Java source are
absolutely defined. Computations on character values cannot produce
variable results. What can vary is the *external* representation on
disk, screen, printer, keyboard, TCP/IP packet, or whatever. This is
because those media almost universally expect 8-bit coding, and there
are any number of possible mappings between those 8-bit values and the
internal 16-bit Unicode values.
In most simple cases, the default mapping (encoding) will do, but
different JVMs running in different environments may have different
default encodings. This can cause trouble if, for example, your program
finds itself running on an IBM mainframe and uses the default EBCDIC
encoding to try to write TCP/IP packet data which has to be in ASCII.
You can always specify a particular encoding, but then you need to be
careful to specify the right encoding for the situation; e.g., don't
force ASCII encoding on an EBCDIC machine if you're outputting to a
native EBCDIC device.
