10 ms·

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?

recursive 5y ago
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?
- xxs 5y ago
  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.
  - recursive 5y ago
    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.
    - eMSF 5y ago
      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.
    - xxs 5y ago
      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)
- rzzzt 5y ago
  Java has both >> and >>> operators for sign-extending and zero-extending right shift, respectively.
sorokod 5y ago
They are present in Kotlin https://kotlinlang.org/docs/basic-types.html#unsigned-integers https://kotlinlang.org/docs/basic-types.html#unsigned-intege...
chrisseaton 5y ago
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.
- da_chicken 5y ago
  This reads like, "VisualBasic already has everything you need for pointers. You can define your own classes and pass by reference."
  - chrisseaton 5y ago
    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.
    - pkolaczk 5y ago
      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.
      - chrisseaton 5y ago
        So yes it's also error-prone. But there's no overhead, as the original comment implied.
5faulker 5y ago
Same here. Can be downright confusing sometimes.
xxs 5y ago
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.
hashmash 5y ago
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.
jatone 5y ago
wait until you learn about signed bytes.

recursive 5y ago

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?

xxs 5y ago
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.
- recursive 5y ago
  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.
  - eMSF 5y ago
    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.
  - xxs 5y ago
    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)
rzzzt 5y ago
Java has both >> and >>> operators for sign-extending and zero-extending right shift, respectively.

sorokod 5y ago

They are present in Kotlin https://kotlinlang.org/docs/basic-types.html#unsigned-integers https://kotlinlang.org/docs/basic-types.html#unsigned-intege...

chrisseaton 5y ago

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.

da_chicken 5y ago
This reads like, "VisualBasic already has everything you need for pointers. You can define your own classes and pass by reference."
- chrisseaton 5y ago
  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.
  - pkolaczk 5y ago
    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.
    - chrisseaton 5y ago
      So yes it's also error-prone. But there's no overhead, as the original comment implied.

5faulker 5y ago

Same here. Can be downright confusing sometimes.

xxs 5y ago

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.

hashmash 5y ago

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.

jatone 5y ago

wait until you learn about signed bytes.