Presumably because you can't represent 1<<31 in a 32-bit signed number.
Nor can int represent -2147483648 (base 16). -2147483648 contains digits
not in base 2 or 8.

Although Integer.toBinaryString and friends create representations of
the number as if it is unsigned, Integer.parseInt treats the value is
normally.

If your data is LSB first, you'll need to reverse it, anyway.
StringBuilder will do that nicely for you.

Tom Hawtin

Integer.toHexString() .  The latter produces hex strings as one would
expect with negatives getting high order bit set and no sign.  The
former accepts input that has an optional "-" followed by a necessarily
positive hex String, with one exception, the Integer.MIN_VALUE's hex
encoding 80000000 (So you can pass in "-80000000" and get
Integer.MIN_VALUE).

In other words the hex string to parseInt (after the optional sign)
needs be lower than or equal to 80000000 in unsigned terms.  I did not
expect that.

Long story short parseInt is not not gonna do the deed.

package experiment;
public class test {
    public static void main(String[] args) {
      int n = 444;
      String hex = Integer.toHexString(n);
      System.out.println(""+n+" in hex is "+hex);
      int back = Integer.parseInt(hex,16);
      int negatively = Integer.parseInt("-"+hex,16);
      System.out.println("back="+back+" negatively="+negatively);
    }
}

Opalinski
opalpa@gmail.com
http://www.geocities.com/opalpaweb/

On Mon, 30 Jan 2006 17:34:58 -0800, Knute Johnson
<nospam@ljr-2.frazmtn.com> wrote, quoted or indirectly quoted someone
who said :

most likely because the author did not write a special case for it.  A
typical parse routine creates an positive binary number then negates
it if it saw the sign. The algorithm won't work for a number without a
positive equivalent. It is a bug, since that number is legit.

nobody tested it since that number usually only comes up in binary
contexts.

see http://mindprod.com/jgloss/bugs.html
on how to report it.