I just read this statement in a java book saying Objects in java reside on a heap. Is a heap used because it is the best way to store data and retrieve data fast ?
I only have an idea about data structures being a beginner. I mean why not stack or something else ?
Because Java uses a garbage collector to reclaim memory, unlike C and C++. In those languages it makes sense to use the stack for local variables*. In Java, there is no concept of a (local) variable going out of scope, only it is not referenced anymore, which makes it eligible for garbage collection (which is bound to happen sometime after that point).
* which, for the sake of clarity, does not mean that there were no heap in C/C++, or that you could not use the malloc/new family to allocate variables to be used solely within local scope.
The problem with a stack is that you can only remove the most recent thing you added. This works fine for local variables, since they come and go as you enter and exit functions, but not so well for arbitrary data who's lifecycle doesn't follow that of individual functions. The memory heap allows you to add and remove data at will.
Why not store objects on the stack? Well, what happens to the stack after the currently executing method stops executing?
The heap is used just by the vm to allocate and deallocate blocks of memory. To access the objects there you use a reference to the block of memory (that reference is in the stack). The jvm doesn't allow direct access to the memory (like in C/C++).
Because objects in Java often outlive the scope within which they were created, at which point the stack frame that was created for the scope ceases to exist.
Allocated heap space on the contrary is not deallocated automatically when the scope within which the object was created no longer exist.
It's an artifact of the underlying computing model. Memory to the operating system looks like a big, mostly contiguous space in which data can be read and written by address. The operating system allows processes to grab a block of memory (a large contiguous space, usually at least one page of a couple K) and to do with that as they like, by using memory addresses and read/write operations.
The java heap builds on that, i.e. to the programmer it just looks like a big bag of memory (it of course is not, i.e. garbage collection routinely moves stuff around) to which he gets "addresses" (references really, they are not actually addresses) for data (objects) written to this memory space. This allows you maximum flexibility to build more specialised data structures on top of that.
Remember that it acts like a "heap" to the programmer, because that allows you the necessary flexibility, but it doesn't have to be implemented as such. It's a piece of memory managed by the garbage collector, and there are a bunch of data structures it uses to do its job, which you could or could not consider part of the heap, i.e. it's memory used and allocated by the JVM, but usually only the memory accessible to the programmer is considered to be "the heap" in this context.