Hacker News Reader

Comment by rdpintqogeogsaa | Hacker News Reader

I've been bitten by bitwise operations on signed integers a few too many times. Are there any plans on having normal unsigned integer types yet?

View on HN

I was griping about Java's lack of unsigned types for over 20 years until it dawned on me why mixing signed and unsigned types together in the same language is a bad idea. Consider when one method returns an unsigned type, but another one accepts a signed type. Signed and unsigned types cannot be safely casted to each other without loss of information, and that causes bigger issues.

The only times the lack of unsigned types causes issues is when doing low-level binary encoding, and most programmers steer clear of that anyhow. I think it's a good tradeoff to make things simpler for most, but a bit more difficult for few.

Other than sign-extension on right shift, I can't think of a bitwise operator that has a different implementation between signed/unsigned. What scenarios are you thinking of?

reading and processing bytes mostly. Many people get confused due to the need of bitwise and, yet even if that would be removed I can't quite see the intrinsic benefits, given how difficult would be having another primitive type.

So, when processing bytes, can you name an operation where the existence of an unsigned type would even make a difference? I'm still not seeing it.

Java bytes are signed. They aren't useful when working with unsigned 8-bit values (say, a scaling factor or an index in whatever binary format you are trying to parse). You need a larger integer type, and indeed that bitwise and operation to get the range of values you need.

java virtually has only 2 integer types int and long, or 4 and 8 bytes one. So all operations are converted to int (or long) 1st, even when they involve byte/short, etc.

Imagine you try to combine a 4bytes (from an array) into a single int. If you just bitwise OR and shift left, e.g. something like

    (b[0] << 24) | (b[1] << 16) | (b[2] << 8) | b[3]

it won't work, you need ((b[1] & 0ff) << 16), etc. The byte values greater than 127 would have the sign bit set (and all other higher bits to make the 2complimentary form)

That part is somewhat alleviated by wrapping byte arrays into ByteBuffers that would the right thing, or even better using only ByteBuffers (preferably the direct version of them when reading from input/output)

Java has both >> and >>> operators for sign-extending and zero-extending right shift, respectively.

They are present in Kotlin

https://kotlinlang.org/docs/basic-types.html#unsigned-intege...

What exactly do you have in mind. Using '&0xff' is annoying but well whatever. Perhaps 23y ago, applying the bitwise and would be a novelty but now it's a minor inconvenience.

The way java is built in internally I can quite see another primitive type popping up.

Same here. Can be downright confusing sometimes.

Java already has everything you need for unsigned integers doesn't it? You just use the normal int type, and then use methods like Integer#compareUnsigned instead of language operators.

This reads like, "VisualBasic already has everything you need for pointers. You can define your own classes and pass by reference."

Not sure what you mean, sorry?

Are you just objecting to the verbosity of method calls over operators? Yes it's a bit annoying, but the functionality is all there.

It is very easy to mess up signed with unsigned then - because they are the same static type. You have to put comments in the code to clarify the interpretation of bits.

So yes it's also error-prone. But there's no overhead, as the original comment implied.

wait until you learn about signed bytes.

Reply on news.ycombinator.com