Hi Mark, As far as I'm aware that's an implementation detail only, not mandated by the spec, so you're right I don't think it's something you can rely on. Having said that, it never used to be an issue when the minimum size allocated to each primitive was 4 bytes! I guess this change must have come in with Java 6. I'm surprised that boolean is only using one byte given that non-aligned access is more expensive than aligned, but I guess the VM implementors have found a way of dealing with that. Also note that Java bytecode only has 4 and 8 byte types, so it really is the VM that's doing all the clever stuff here, not the compiler. In response to an earlier comment of yours: "If the Java implementers are smart they would be stored as single bits rather than bytes/shorts/words. Perhaps someone who knows about this could comment" I don't pretend to know all that much about what it would take to implement this properly, but my understanding is that this isn't really feasible because operations on the bits would need to be performed atomically to prevent race conditions against the other booleans, and that becomes very expensive. It's quite interesting how the extra level of abstraction the VM provides makes these sort of optimisations a moving target. Chris MB> Here's something else I guess you shouldn't depend on: MB> MB> further experimentation shows that the order of the class member MB> declarations doesn't make any difference to the object size. So you MB> can MB> intersperse the bools with the ints and the object size doesn't MB> change. MB> The Java compiler must order the fields to minimise the space MB> required. MB> That's fine because (not being C) you can't address the object's MB> fields by pointer so the ordering is not visible to the programmer. MB> Cheers, MB> MB> Mark