Do Java primitives go on the Stack or the Heap?

Primitives defined locally would be on the stack. However if a primitive were defined as part of an instance of an object, that primitive would be on the heap.

public class Test {    private static class HeapClass {        public int y; // When an instance of HeapClass is allocated, this will be on the heap.    }    public static void main(String[] args) {        int x=1; // This is on the stack.    }}

With regards to the update:

Objects do not have their own stack. In my example, int y would actually be part of each instance of HeapClass. Whenever an instance of HeapClass is allocated (e.g. new Test.HeapClass()), all member variables of HeapClass are added to the heap. Thus, since instances of HeapClass are being allocated on the heap, int y would be on the heap as part of an instance of HeapClass.

However, all primitive variables declared in the body of any method would be on the stack.

As you can see in the above example, int x is on the stack because it is declared in a method body--not as a member of a class.

All local variables (including method arguments) go on the stack; objects and all their fields are stored in the heap. Variables are always primitives or references to objects.

Java implementations may actually store objects on the heap in such a way that it still complies with the specification. Similarly local variables may be stored in registers or become indistinct through optimisation.

primitives can be found in both places.

class Foo{   public int x;   public static void Main()   {      int y = 3; // y is on the stack      Foo f = new Foo();  // f.x is probably on the heap   } }

except you shouldn't really care unless you're building a JVM. A really clever optimizer might decide that since the Foo that f points to never escapes Main, and is never passed to another function that it is safe to allocate it on the stack.

With regards to the update:

The stack and the heap aren't distinguished by what is stored in them, but rather the operations provided for them. The stack allows you to allocate a piece of memory in a LIFO fashion, you can't deallocate a piece until all the pieces younger than it have also been deallocated. This conveniently aligns with how a call stack is used. You can put anything on the stack as long as it is ok for that thing to go away when your function returns. This is an optimization, as it is very quick to allocate and deallocate from a stack since it only supports being used in this manner. One could store all the local variables for a function on the heap in an implementation if one wanted to. The heap is more flexible, and consequently more expensive to use. It would not be accurate to say that an object has a stack and a heap, as I said, what distinguishes the stack from the heap is not what is in it, but the available operations.