Java's boxing (you can't put an int in a HashMap without first copying it to the heap) and lack of value types (basically the same problem for structs) does impose some extra object references and headers other languages wouldn't require.

It's not that much overhead and Java has successfully been used in the embedded space for a long time. (The JVM is separate from the Java language.) From today's wiki page on embedded java, "Embedded Java minimal requirements start at 30KB of (internal) flash and less than 2KB of (internal) RAM." Sure sometimes you can't even meet that, but that's hardly Java's fault.

IME, it's not so much the amount of memory¹, as the pressure it places on the GC to keep up w/ these (often small, but numerous) allocations. Other languages can allocate and deallocate these types of structures with just a stack pointer move in both cases, since nothing ever leaves the stack. (I think Java's allocator is typically approximately or exactly as cheap as a pointer-move on allocation, but deallocation is another story.)

¹but I don't want to downplay this concern entirely; in the parent's case of an int needing boxing, that effectively doubles the cost: the int, and now the pointer to that int. (Plus any hidden requirements of the allocator, but even if we assume that's free, the story might still be plenty grim.)

>that effectively doubles the cost: the int, and now the pointer to that int.

Empty objects aren't free either, so you pay triple.