The specification for the jvm does not specify how it packs data into memory. Different jvm's and different platforms may pack data more tightly or loosely than others. The the standard sun JVM does pack memory to 8bit boundaries. You can test this yourself by creating a simple program with a size million array of bytes and another with a size million array of integers and them measure the difference in the size of the vm. Blank Expression is wrong about memory usage, at least as it relates to the standard sun jvm.
Note that replying to qwerty was in regards to his ill-advised C-based advice, not anything related to Java. Without (compiler-specific) pragmas and a decent bit of inefficient dicking around, every x86[_64] C/C++ compiler aligns to word boundaries (and doing otherwise is counterproductive). (If I had been referring to Java, it would have been a little odd to be talking about pointers, no?)
You are correct with respect to Java--
if you use nothing but arrays (which are special-cased). Using any other collections, or operations where you must box the primitives, results in a loss of any space benefit. Some quick tests on the 6.0 JRE, with arrays of 1,000,000 elements (just getting total used memory from Runtime):
short: 3419808
int: 5419808
Short: 9419808
Integer: 9419808
That said, memory use isn't the problem I was referring to. Memory is cheap. Inefficient data requesting, and essentially throwing away big whacks of every memory request, isn't. While I personally am of the opinion that it's better to use reasonably-domained data types, if you're going to be obsessive and "OCD" (his word, not mine), you benefit more from using ints wherever possible (and longs on x86_64). Using a non-machine-word sized value means you're making a word-size memory request and just masking off the rest of the bits. Mask-and-shift is not as cheap as just using the whole word. (There are special cases for using 4-byte words on x64, but that's getting into deep magic.)
Of course,
this isn't important, which is what I was getting at. That these sorts of "optimizations" aren't, and are counterproductive in the long run. And the medium run. Also the short run, too, really. I don't think you and I actually disagree here.