Why doesn't Java support unsigned ints?

Question

Why doesn't Java include support for unsigned integers? It seems to me to be an odd omission, given that they allow one to write code that is less likely to produce overflows on unexpectedly large input. Furthermore, using unsigned integers can be a form of self-documentation, as they indicate that the value that the unsigned int was intended to hold is never supposed to be negative. Lastly, in some cases, unsigned integers can be more efficient for certain operations, such as division. What's the downside to including these?

Answer 1

http://skeletoncoder.blogspot.com/2006/09/java-tutorials-why-no-unsigned.html

This guy says because the C standard defines operations involving unsigned and signed ints to be treated as unsigned. This could cause negative signed integers to roll around into a large unsigned int, potentially causing bugs.

Answer 2

This is from an interview with Gosling and others, about simplicity:

Gosling: For me as a language designer, which I don't really count myself as these days, what "simple" really ended up meaning was could I expect J. Random Developer to hold the spec in his head. That definition says that, for instance, Java isn't -- and in fact a lot of these languages end up with a lot of corner cases, things that nobody really understands. Quiz any C developer about unsigned, and pretty soon you discover that almost no C developers actually understand what goes on with unsigned, what unsigned arithmetic is. Things like that made C complex. The language part of Java is, I think, pretty simple. The libraries you have to look up.

Answer 3

I've heard stories that they were to be included close to the orignal Java release. Oak was the precursor to Java, and in some spec documents there was mention of usigned values. Unfortunately these never made it into the Java language. As far as anyone has been able to figure out they just didn't get implemented, likely due to a time constraint.

Answer 4

As soon as signed and unsigned ints are mixed in an expression things start to get messy and you probably will lose information. Restricting Java to signed ints only really clears things up. I’m glad I don’t have to worry about the whole signed/unsigned business though I sometimes do miss the 8th bit in a byte. :)

Answer 5

Reading between the lines, I think the logic was something like this:

• generally, the Java designers wanted to simplify the repertoire of data types available
• for everyday purposes, they felt that the most common need was for signed data types
• for implementing certain algorithms, unsigned arithmetic is sometimes needed, but the kind of programmers that would be implementing such algorithms would also have the knowledge to "work round" doing unsigned arithmetic with signed data types

Mostly, I'd say it was a reasonable decision. Possibly, I would have:

• made byte unsigned, or at least have provided a signed/unsigned alternatives, possibly with different names, for this one data type (making it signed is good for consistency, but when do you ever need a signed byte?)
• done away with 'short' (when did you last use 16-bit signed arithmetic?)

Still, with a bit of kludging, operations on unsigned values up to 32 bits aren't tooo bad, and most people don't need unsigned 64-bit division or comparison.

Answer 6

I think Java is fine as it is, adding unsigned would complicate it without much gain. Even with the simplified model most Java programmers don't know how the basic numeric types behave, just read the book "Java Puzzlers" and you will know what I mean.

As for practical advice:

If your values are somewhat arbitrary size and don't fit into int, use long. If they don't fit into long use BigInteger.

Use the smaller types only for arrays when you need to save space.

If you need exactly 64/32/16/8 bits, use long/int/short/byte and stop worrying about the sign, except for division and comparison.

See also this answer.

Answer 7

I can think of one unfortunate side-effect. In java embedded databases, the number of ids you can have with a 32bit id field is 2^31, not 2^32 (~2billion, not ~4billion).

Answer 8

Java does have unsigned types, or at least one: char is an unsigned short. So whatever excuse Gosling throws up it's really just his ignorance why there are no other unsigned types.

Also Short types: shorts are used all the time for multimedia. The reason is you can fit 2 samples in a single 32-bit unsigned long and vectorize many operations. Same thing with 8-bit data and unsigned byte. You can fit 4 or 8 samples in a register for vectorizing.

Answer 9

Having java add ubyte, ushort, uint, and ulong to the primitive data types couldent be very hard. Maybe a few more wrapper classes but thats about it and lots of modifications to have the java compiler/runtime to support it. But in the end it would be a good thing. And another thing to add to this topic why dont they allow us to use longs with arrays. Someone might have more memory than 2.147483647 gb of memory. I know a guy who has 20gb of ram.

Answer 10

The only unsigned type that I really care about and would like to have added is unsigned byte. For larger types like int or long, i don't really care if they are all signed.