[hashmash]

The problem with having unsigned integer types is that it introduces new type conversion issues. If you call a method that returns an unsigned int, how do you safely pass it to a method that accepts an int? Or vice versa? A smaller set of primitive types is preferred, since it has fewer conversion issues.

Unsigned integer types are only really necessary when dealing with low-level bit manipulation, but most programs don't do this. The lack of unsigned integers makes low-level stuff a bit more difficult, but it makes the language as a whole much easier. It's a good tradeoff.

[TuxSH]

> If you call a method that returns an unsigned int, how do you safely pass it to a method that accepts an int?

Mandate 2's complement be used.

> Unsigned integer types are only really necessary when dealing with low-level bit manipulation

They also give one more bit of precision, useful when dealing with 32-bit integers (or below)

[binarymax]

Literally every other language with unsigned types handles this just fine?

[hashmash]

I guess it depends on what "just fine" means. What happens when a conversion is applied? Is there silent data corruption (C), or is there an exception (Ada, D) or perhaps a panic (Rust, Zig)? Is the behavior dependent on compiler flags?

Keeping unsigned integer types out of the language makes things much simpler, and keeping things simple was an original design goal of Java.

[pron]

By no means do C or C++ handle unsigned types just fine. In fact, they're widely recognised as a source of problems even by those who think they're useful (when used carefully).