Can we make unsigned byte in Java

Question

I am trying to convert a signed byte in unsigned. The problem is the data I am receiving is unsigned and Java does not support unsigned byte, so when it reads the data it treats it as signed.

I tried it to convert it by the following solution I got from Stack Overflow.

public static int unsignedToBytes(byte a)
{
    int b = a & 0xFF;
    return b;
}

But when again it's converted in byte, I get the same signed data. I am trying to use this data as a parameter to a function of Java that accepts only a byte as parameter, so I can't use any other data type. How can I fix this problem?

Doublecheck

Guava: UnsignedBytes.toint(byte value) – Chammy

java.lang.Byte.toUnsignedInt(byte value); – Warrior

Answer 1

I'm not sure I understand your question.

I just tried this and for byte -12 (signed value) it returned integer 244 (equivalent to unsigned byte value but typed as an int):

  public static int unsignedToBytes(byte b) {
    return b & 0xFF;
  }

  public static void main(String[] args) {
    System.out.println(unsignedToBytes((byte) -12));
  }

Is it what you want to do?

Java does not allow to express 244 as a byte value, as would C. To express positive integers above Byte.MAX_VALUE (127) you have to use a different integral type, like short, int or long.

Spoof

byte b = (byte)unsignedToBytes((byte) -12); now try printing b – Heterolysis

Why have you accepted this as the correct answer? All it does is exactly the same as the method you mention in your question - convert a byte to an unsigned integer. – Gothicism

It's important to sometimes have signed values, sometimes unsigned, so probably this is the reason he accepted this answer. (byte)(b & 0xff) doesn't have any sense, but (byte)(Math.min((b & 0xff)*2, 255)) has sense, eg in computer graphics it will just make the pixed represented by the byte two times brighter. :-) – Bugbee

It could be called byteToUnsigned too – Stearns

Answer 2

The fact that primitives are signed in Java is irrelevant to how they're represented in memory / transit - a byte is merely 8 bits and whether you interpret that as a signed range or not is up to you. There is no magic flag to say "this is signed" or "this is unsigned".

As primitives are signed the Java compiler will prevent you from assigning a value higher than +127 to a byte (or lower than -128). However, there's nothing to stop you downcasting an int (or short) in order to achieve this:

int i = 200; // 0000 0000 0000 0000 0000 0000 1100 1000 (200)
byte b = (byte) 200; // 1100 1000 (-56 by Java specification, 200 by convention)

/*
 * Will print a negative int -56 because upcasting byte to int does
 * so called "sign extension" which yields those bits:
 * 1111 1111 1111 1111 1111 1111 1100 1000 (-56)
 *
 * But you could still choose to interpret this as +200.
 */
System.out.println(b); // "-56"

/*
 * Will print a positive int 200 because bitwise AND with 0xFF will
 * zero all the 24 most significant bits that:
 * a) were added during upcasting to int which took place silently
 *    just before evaluating the bitwise AND operator.
 *    So the `b & 0xFF` is equivalent with `((int) b) & 0xFF`.
 * b) were set to 1s because of "sign extension" during the upcasting
 *
 * 1111 1111 1111 1111 1111 1111 1100 1000 (the int)
 * &
 * 0000 0000 0000 0000 0000 0000 1111 1111 (the 0xFF)
 * =======================================
 * 0000 0000 0000 0000 0000 0000 1100 1000 (200)
 */
System.out.println(b & 0xFF); // "200"

/*
 * You would typically do this *within* the method that expected an 
 * unsigned byte and the advantage is you apply `0xFF` only once
 * and than you use the `unsignedByte` variable in all your bitwise
 * operations.
 *
 * You could use any integer type longer than `byte` for the `unsignedByte` variable,
 * i.e. `short`, `int`, `long` and even `char`, but during bitwise operations
 * it would get casted to `int` anyway.
 */
void printUnsignedByte(byte b) {
    int unsignedByte = b & 0xFF;
    System.out.println(unsignedByte); // "200"
}

Gothicism

For many operations it makes no diference, however for some operations it does. Either way you can use a byte as unsigned, or use char which is unsigned. – Runion

Accessing an array with a potentially negative number is not irrelevant. – Yevette

@Yevette - I meant irrelevant in the context of how they're represented on the wire. – Gothicism

Which is somewhat irrelevant to the question. Since he mentioned that he needs to pass it to a function that only accepts byte parameters it does not matter weather we interpret it as the byte representation of a unicorn. Java will always treat it as a signed number, which can be problematic for an example when this function uses the parameter as an index. However to be fair i also downvoted the other top 2 answers, since they do not answer the question either. – Yevette

@Yevette +1 for you. Absolutely relevant if you are using the byte to access an array of 256 elements. That's an excellent example to demonstrate why everyone should start learning C and C++ before moving to Java or C# – Lubricity

Arrays in Java are indexed using integers only. – Gothicism

@Adamski, yes, but if you do arr[someByte] then someByte will be automatically promoted to an int with sign extension. So, while you may interpret the 8 bits any way you want, Java as a language, will interpret it as a signed value. – Attend

The result of when things are "promoted" to int. int i = b will assign as signed. int i = (byte)b the same. 0xFF as a constant is an int in java you will get acompile error when trying to assign it to a byte. so to make suer the high bit is not extended you need to use int i = b & 0x0FF; – Norinenorita

@PeterLawrey in Java bytes are 8 bits whereas chars are 16 bits, so it makes a difference for bit-sensitive operations. – Marozik

Answer 3

Complete guide for working with unsigned bytes in Java:

Unsigned byte in Java

(Source for this answer.)

---

The Java Language does not provide anything like the unsigned keyword. A byte according to the language spec represents a value between −128 - 127. For instance, if a byte is cast to an int Java will interpret the first bit as the sign and use sign extension.

That being said, nothing prevents you from viewing a byte simply as 8 bits and interpret those bits as a value between 0 and 255. Just keep in mind that there's nothing you can do to force your interpretation upon someone else's method. If a method accepts a byte, then that method accepts a value between −128 and 127 unless explicitly stated otherwise.

Here are a couple of useful conversions / manipulations for your convenience:

Conversions to / from int

// From int to unsigned byte
int i = 200;                    // some value between 0 and 255
byte b = (byte) i;              // 8 bits representing that value

// From unsigned byte to int
byte b = 123;                   // 8 bits representing a value between 0 and 255
int i = b & 0xFF;               // an int representing the same value

(Or, if you're on Java 8+, use Byte.toUnsignedInt.)

Parsing / formatting

Best way is to use the above conversions:

// Parse an unsigned byte
byte b = (byte) Integer.parseInt("200");

// Print an unsigned byte
System.out.println("Value of my unsigned byte: " + (b & 0xFF));

Arithmetics

The 2-complement representation "just works" for addition, subtraction and multiplication:

// two unsigned bytes
byte b1 = (byte) 200;
byte b2 = (byte) 15;

byte sum  = (byte) (b1 + b2);  // 215
byte diff = (byte) (b1 - b2);  // 185
byte prod = (byte) (b2 * b2);  // 225

Division requires manual conversion of operands:

byte ratio = (byte) ((b1 & 0xFF) / (b2 & 0xFF));

Attend

Answer 4

There are no primitive unsigned bytes in Java. The usual thing is to cast it to bigger type:

int anUnsignedByte = (int) aSignedByte & 0xff;

Kohlrabi

Is the cast to an int necessary? – Solfa

It can be an implicit cast, but there's a cast either way. And that cast does signed extension. And that is a problem. If you do an explicit cast, you can at least see this is happening. – Gilman

Answer 5

I think the other answers have covered memory representation and how you handle these depends on the context of how you plan on using it. I'll add that Java 8 added some support for dealing with unsigned types. In this case, you could use Byte.toUnsignedInt

int unsignedInt = Byte.toUnsignedInt(myByte);

Frottage

Answer 6

A side note, if you want to print it out, you can just say

byte b = 255;
System.out.println((b < 0 ? 256 + b : b));

Platas

why so complex? println(b & 0xff) is enough – Kegan

Answer 7

You can also:

public static int unsignedToBytes(byte a)
{
    return (int) ( ( a << 24) >>> 24);
}    

Explanation:

let's say a = (byte) 133;

In memory it's stored as: "1000 0101" (0x85 in hex)

So its representation translates unsigned=133, signed=-123 (as 2's complement)

a << 24

When left shift is performed 24 bits to the left, the result is now a 4 byte integer which is represented as:

"10000101 00000000 00000000 00000000" (or "0x85000000" in hex)

then we have

( a << 24) >>> 24

and it shifts again on the right 24 bits but fills with leading zeros. So it results to:

"00000000 00000000 00000000 10000101" (or "0x00000085" in hex)

and that is the unsigned representation which equals to 133.

If you tried to cast a = (int) a; then what would happen is it keeps the 2's complement representation of byte and stores it as int also as 2's complement:

(int) "10000101" ---> "11111111 11111111 11111111 10000101"

And that translates as: -123

Surpassing

In 2019, this is unnecessary. Just use java.lang.Byte.toUnsignedInt(byte value). And if you are not using Java 8 yet, upgrade ASAP. Java 7 and earlier are end-of-life. – Chappell

I think this old-school alternative is still instructive. For those who are wondering about the difference between '>>' and '>>>', here is the documentation: The signed left shift operator "<<" shifts a bit pattern to the left, and the signed right shift operator ">>" shifts a bit pattern to the right. The unsigned right shift operator ">>>" shifts a zero into the leftmost position, while the leftmost position after ">>" depends on sign extension. – Overlooker

Answer 8

Although it may seem annoying (coming from C) that Java did not include unsigned byte in the language it really is no big deal since a simple "b & 0xFF" operation yields the unsigned value for (signed) byte b in the (rare) situations that it is actually needed. The bits don't actually change -- just the interpretation (which is important only when doing for example some math operations on the values).

Narra

look others answer, you think your answer is best/helpful? describe in little and add it in comments – Sociable

It's not rare just because you've not come across it. Try implementing a protocol and you will come across this a million times. The annoying thing is that the vast majority of use cases I've come across that deal with bytes, you want to deal with unsigned bytes (because they're bytes, not numbers). The crazy thing is that ANY bitwise operation will convert it to an int, which means any "negative" values will be completely different values when extended. Yes, you can get around it by always masking, but it's a waste of time, processor, and causes really obscure bugs if you forget. – Bayard

I agree with Thor84no: bytes are not numbers, and should not have sign. On the other side, since they are not numbers we should not even have/use the + and - operators. Using only bitwise operators works fine, on the other side shift operators don't work as one would like, and indeed java promotes a shifted byte to an int. – Sheik

@VlastimilOvčáčík That's literally impossible in this case, that's the agitating thing. You EITHER repeat x & 0xFF everywhere you need it or you repeat something like behaveLikeAnUnsignedByte(x) everywhere. This is needed for every single place you use a byte value or a byte array that needs to be unsigned, there is no conceivable way of avoiding this repetition. You cannot write the implementation of a protocol that reads and writes byte values with only a single reference to a byte variable. Your simplistic view might explain why they never cared to fix it though. – Bayard

Answer 9

Adamski provided the best answer, but it is not quite complete, so read his reply, as it explains the details I'm not.

If you have a system function that requires an unsigned byte to be passed to it, you can pass a signed byte as it will automatically treat it as an unsigned byte.

So if a system function requires four bytes, for example, 192 168 0 1 as unsigned bytes you can pass -64 -88 0 1, and the function will still work, because the act of passing them to the function will un-sign them.

However you are unlikely to have this problem as system functions are hidden behind classes for cross-platform compatibility, though some of the java.io read methods return unsighed bytes as an int.

If you want to see this working, try writing signed bytes to a file and read them back as unsigned bytes.

Waxwing

There is no such thing as signed or unsigned bytes. – Advanced

How exactly were you writing and reading the bytes in your example? – Advanced

Answer 10

If think you are looking for something like this.

public static char toUnsigned(byte b) {
    return (char) (b >= 0 ? b : 256 + b);
}

Anjaanjali

Answer 11

I am trying to use this data as a parameter to a function of Java that accepts only a byte as parameter

This is not substantially different from a function accepting an integer to which you want to pass a value larger than 2^32-1.

That sounds like it depends on how the function is defined and documented; I can see three possibilities:

1. It may explicitly document that the function treats the byte as an unsigned value, in which case the function probably should do what you expect but would seem to be implemented wrong. For the integer case, the function would probably declare the parameter as an unsigned integer, but that is not possible for the byte case.

2. It may document that the value for this argument must be greater than (or perhaps equal to) zero, in which case you are misusing the function (passing an out-of-range parameter), expecting it to do more than it was designed to do. With some level of debugging support you might expect the function to throw an exception or fail an assertion.

3. The documentation may say nothing, in which case a negative parameter is, well, a negative parameter and whether that has any meaning depends on what the function does. If this is meaningless then perhaps the function should really be defined/documented as (2). If this is meaningful in an nonobvious manner (e.g. non-negative values are used to index into an array, and negative values are used to index back from the end of the array so -1 means the last element) the documentation should say what it means and I would expect that it isn't what you want it to do anyway.

Torse

Hmmm, I think I just posted a reply that was intended for another question about the signedness of bytes, but I suppose it is still a bit relevant here too... – Torse

Answer 12

I happened to accidentally land on this page after wondering about the apparent asymmetry of the netty ByteBuf writeInt and readUnsignedInt methods.

After reading the interesting and educational answers I am still wondering what function you were calling when you said:

I am trying to use this data as a parameter to a function of Java that accepts only a byte as parameter.

For what it's worth after so many years, here is my fifty cents:

Let's assume the method you are calling is updating some balance with micro amounts and that it behaves according to some well-defined set of requirements. Ie, it is considered to have a correct implementation for its intended behavior:

long processMicroPayment(byte amount) {
    this.balance += amount;
    return balance;     
}

Basically, if you supply a positive amount it will be added to the balance, and a negative amount will effectively be subtracted from the balance. Now because it accepts a byte as its parameter the implicit assumption is that it functionally only accepts amounts between -128 and +127. So if you want to use this method to add, say, 130 to the balance, it simply will not produce the result YOU desire, because there is no way within the implementation of this method to represent an amount higher than 127. So passing it 130 will not result in your desired behavior. Note that the method has no way of implementing a (say) AmountOutOfBoundsException because 130 will be 'interpreted' as a negative value that is still obeying the method's contract.

So I have the following questions:

• are you using the method according to its (implicit or explicit) contract?
• is the method implemented correctly?
• am I still misunderstanding your question?

Woodpile

Answer 13

There is no unsigned byte in Java, but if you want to display a byte, you can do,

int myInt = 144;

byte myByte = (byte) myInt;

char myChar = (char) (myByte & 0xFF);

System.out.println("myChar :" + Integer.toHexString(myChar));

Output:

myChar : 90

For more information, please check, How to display a hex/byte value in Java.

Oloughlin

There's no need for defining this yourself. java.lang.Byte.toUnsignedInt(byte value); exists for this. – Pansypant

Answer 14

Yes and no. Ive been digging around with this problem. Like i understand this:

The fact is that java has signed interger -128 to 127.. It is possible to present a unsigned in java with:

public static int toUnsignedInt(byte x) {
    return ((int) x) & 0xff;
}

If you for example add -12 signed number to be unsigned you get 244. But you can use that number again in signed, it has to be shifted back to signed and it´ll be again -12.

If you try to add 244 to java byte you'll get outOfIndexException.

Cheers..

Wilinski

There's no need for defining this yourself. java.lang.Byte.toUnsignedInt(byte value); exists for this. – Pansypant

Answer 15

If you have a function which must be passed a signed byte, what do you expect it to do if you pass an unsigned byte?

Why can't you use any other data type?

Unsually you can use a byte as an unsigned byte with simple or no translations. It all depends on how it is used. You would need to clarify what you indend to do with it.

Runion

Answer 16

As per limitations in Java, unsigned byte is almost impossible in the current data-type format. You can go for some other libraries of another language for what you are implementing and then you can call them using JNI.

Dira

I don't think he wants to store it as a signed byte. He is receiving it as a signed byte, and he wants to store it as an int, which is perfectly valid. His problem is that wherever he is getting input from is representing a value between 0 and 255 as a byte, but Java interprets that as a twos complement signed value because java doesn't support signed bytes. – Footpath

Answer 17

If you want unsigned bytes in Java, just subtract 256 from the number you're interested in. It will produce two's complement with a negative value, which is the desired number in unsigned bytes.

Example:

int speed = 255; //Integer with the desired byte value
byte speed_unsigned = (byte)(speed-256);
//This will be represented in two's complement so its binary value will be 1111 1111
//which is the unsigned byte we desire.

You need to use such dirty hacks when using leJOS to program the NXT brick.

Zion

You do realize that the binary value of 255 is also 1111 1111, so no substraction is necessary, right? – Beating

@NickWhite, yes in binary. But java uses's 2's comlement where 255 is not 11111111 – Zion

Sorry, but this is just wrong. Try some experiments. The value in speed_unsigned is signed. Print it and see. (And the - 256 achieves nothing here.) – Chappell