Little-Endian mode for MIPS processors was sometimes called SPIM, so I guess little-endian POWER is REWOP. I never heard little-endian SPARC referred to as CRAPS, which is too bad as I thought that was pretty funny.
The old PowerPC processors did this by flipping the low bits of memory addresses when in little-endian mode, but the data lanes had to be reversed to make this work. So back in the day, it only meant that you could use the same chip for a little-endian design but not the same motherboard. I don't think that's how newer POWER processors work, though.
Correction: a modified memory controller wasn't necessary as long as all of your memory accesses were naturally aligned. As I remember, in little-endian mode, unaligned accesses would also trap to the kernel, so kernel authors could include code that would fix things up, at a huge performance penalty for unaligned access.
Most architectures that support unaligned access have a small penalty for unaligned access anyway, and some architectures (Does anyone remember Netscape Navigator on Solaris SPARC crashing with SIGBUS much more often than the same Navigator release crashing on x86? At least Solaris 6/7 didn't include kernel code to emulate support for aligned memory access on SPARC.) don't support it, so it's best to avoid unaligned memory access in C code.
I don't recall the JVM specification forcing a particular object layout on an implementation, and I believe most JVM implementations naturally align all object fields rather than packing them for minimum space usage. I believe an implementation could reorder the fields in order to optimally pack them while avoiding unaligned accesses, at the cost of breaking any hand optimization of locality of reference made by the programmer. However, I think the space savings for almost all programs would be very meager.
