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. s

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.