> This is a C-like can of worms, forcing you to test on more platforms just to be sure that you have portable code. Hardly. If you need fixed integer widths, u

> This is a C-like can of worms, forcing you to test on more platforms just to be sure that you have portable code. Hardly. If you need fixed integer widths, use the fixed integer width types. If you need types that are 'optimal' for the target architecture, use the non-fixed-width types. The only time you run into trouble is when you make silly assumptions about the width of non-fixed width types, which is a bad idea in almost any language that doesn't vend automatic "bignum" scaling integers. It's not as if you can ignore the width of the types in Java. Apple does the same thing themselves with ObjC; NSUInteger/NSInteger are uint32 on 32-bit systems, uint64 on 64-bit systems. All in-memory lengths, counts, sizes, etc (but not offsets) are defined as NS(U)Integer values. I've done the same in my own code that's portable from 8-bit to 64-bit CPUs. Works out just fine. Java is itself an odd duck; using fixed-width signed types without also offering unsigned variants has been a plague on every single person who has ever had to parse binary data in Java, ever.