Any other variations such as :
int i = b<0 ? b+256 : b;
are maybe simplier to read, but heavier in terms of performance.

Now to Ellie's version. It returns 14, however because of operator precedence.
The actual "correct" formula he meant (I think so at least) is:
int num = 16 * ((mySignedByte & 0xf0) >> 4) + (mySignedByte & 0x0f);
Otherwise the last &0x0f will be executed last and trim the 4 MSBs.

It is correct btw, but the question here is why to do it, since it’s actually &0xff.
And the pattern 16 * (X >> 4) is a nice way to obfuscate identity, kinda pseudo-security by obscurity

Vadim.

Not sure what is pseudocode expected to do. For 0xFE case (signed byte -2) the equation returns 14;
Bit-shifting and multiplying is not needed to trim the sign by half-bytes.

To fix it, mySignedByte&0xf0+(mySignedByte&0x0f) would work (equally to mySignedByte&0xff).

Well, this hard method is behaving like it should – preserves the sign – so no help:

“byte mySignedByte = 0xFE;” is illegal code (cannot convert from int to byte) so one should either use
“(byte) 0xFE;” or “Integer.valueOf(0xFE).byteValue();”.

Both give signed byte (-2 for this case).

Next, Byte.valueOf(mySignedbyte).intValue() gives back -2, signed int.

Byte is signed, however we tweak the bits and intValue() is and should respect the sign bit.

Though if you have, say:
byte mySignedByte = 0xFE; // = 254 decimal

You can also do (pseudo code) :
int num = 16 * ((mySignedByte & 0xf0) >> 4) + mySignedByte & 0x0f

And of course there is the hard method:
int num = Byte.valueOf(mySignedbyte).intValue();

Sincerely,

Ellie P.