Hacker News Reader

Comment by StefanKarpinski | Hacker News Reader

Fully agree with this, although one case where Java’s lack of unsigned integers is a quite bad is in representing binary data because the byte type is signed. I recently had cause to write some Java code that did a lot of modular arithmetic with arrays of bytes and oof, what a mess. There were four or five subtle bugs caused by the unexpected signedness of the byte type. I also wrote the same thing in Julia using UInt8 vectors and had no such bugs.

View on HN

Java technically doesn't even have non-array bytes (or short), all types are just that integers: either 4 or 8 bytes. So if you see a declaration of byte/short (and often times char) is likely a mistake.

The correct way is using ints, e.g. "int x = b[i] & 0xff;". Pretty much you should do math with int and long only. java.util.Integer/Long nowadays have static methods to work with unsigned types if you need them.

Once you remember that you need (the annoying) "0xff", you'll be free from errors. It has been there for 24 or so years. Other than that wrap your arrays into ByteBuffer and use provided utility.

Citation needed? Java primitive fields are padded for alignment, but that's not unique to java.

https://www.baeldung.com/java-memory-layout#layout

It's pretty much a part of the bytecode spec [0]. The stack model has only 4 or 8 bytes long operands. Yes, it can convert int to byte, as method signitures actually need the cast. However a operation involving two bytes (say add, sub, shift) would result into an int, and requires a downcast back to byte. "b+=anotherByte" sums b and anotherByte and then downcasts it automatically.

The memory layout of the classes is quite immaterial here as the operation do happen within CPU registers.

[0]: https://docs.oracle.com/javase/specs/jvms/se12/html/index.ht... [1]: https://en.wikipedia.org/wiki/List_of_Java_bytecode_instruct...

This is true, but if your runtime is actually running stack-based interpretation of your java code (rathe than JIT) you have bigger performance problems.

    static int square(int);
       0: iload_0
       1: iload_0
       2: imul
       3: ireturn

is java; compare to the c++ equivalent (used unsigned to avoid any possibility of undefined behavior):

    unsigned char square(unsigned char num) {
      return num * num;
    }

Which compiles to:

        mov     eax, edi
        imul    eax, edi
        ret

on x86

        mul     w0, w0, w0
        ret

on arm.

By this definition, c and c++ don't have "real" byte types either, because they undergo integer promotion for operations, and the generated code is operating on register sized values, not bytes. Java bytes use 8 bits as part of an object (with a fixed-cost padding); 8 bits as part of an array, etc. The fact that the bytecode has intermediate casts is not relevant to the actual code executed on CPU.

> By this definition, c and c++ don't have "real" byte types either, because they undergo integer promotion for operations, and the generated code is operating on register sized values

They're not actually operating on register-sized values: the code labelled x86 is also the x64 code, meaning GCC operates on 32b when the native registers are 64b. Likewise ARM.

Your assertion is even more debatable when Clang actually operates on 8-bit registers on x64:

        mov     eax, edi
        mul     al
        ret

(it does not on ARM64 as `mul` is only defined for 32 and 64b)

I don't write Java, but a good way to deal with this might be to cast to int (a larger type) immediately after loading a byte and before working with it. So, complexity-wise, the overhead of signed byte vs unsigned byte should be at most two casts, and often casting to a larger type would be required anyway even for operations with unsigned byte values.

Reply on news.ycombinator.com