0

Why is it that toHexString prints different strings in what appears to be very specific circumstances? Printing a number below 0x80000000 works just fine. Adding 1 to that value and printing it works fine. But assigning that value directly does not print the same thing, instead I have to add an L to the end.

My guess is that it has to do with the fact that numeric literals are of type int by default, but I don't know this happens at 0x80000000 and not when crossing over 0xffffffff for instance.

long a = 0x7FFFFFFF;
System.out.println(java.lang.Long.toHexString(a)); // prints 7fffffff

a++;
System.out.println(java.lang.Long.toHexString(a)); // prints 80000000


long b = 0x80000000;
System.out.println(java.lang.Long.toHexString(b)); // prints ffffffff80000000

b=0x80000000L;
system.out.println(java.lang.Long.toHexString(b)); // prints 80000000

P.S. Why doesn't oracle or tutorialspoint say anything about how methods are implemented? Where can I find the implementation of the standard libraries?

Deoxal
  • 226
  • 1
  • 2
  • 9

1 Answers1

1

That has nothing to do with the toHexString method, it's all about int vs long in Java, and binary representation of signed integers.

When you write

long b = 0x7FFFFFFF;

and

long b = 0x80000000;

the literal number on the right is interpreted as an int (32 bits). Now, in the second case that value overflows the (signed) integer positive range, its binary represantion has a 1 in the leftmost position, and hence the number is understood as negative (-2147483648). Afterwards, in the assignment, it's promoted to a (negative) long, so the extra 32 bits are filled with ones. That's why you see those "extra" FFF...

If you don't know about the binary representation of signed integers in Java, read here

leonbloy
  • 73,180
  • 20
  • 142
  • 190
  • I understand two's complement, but I don't know when I can safely omit the L at the end of a literal. I even mentioned that literals are inferred to be ints and that it had to do with that. But since I'm not passing a literal into the method I'm still confused. By incremting a, the extra f's from becoming a negative number don't appear. That is the part that confuses me. – Deoxal Oct 14 '18 at 07:00
  • Before you increment `a` , you have a long value (positive in this case), the literal has been promoted to 64 bits. Then, the increment corresponds to `a = a +1` but this sum is done as long (64 bits), so there is no overflow/crossing. Forget about the `toHexString` method . Try inserting a plain `System.out.printl(a)` and `System.out.printl(b)` to understand what is happening. To represent the number in hexa is good to get the binary representation, but it makes less evident if the number is positive or negative. – leonbloy Oct 14 '18 at 14:17