Notionally, the object goes on "the heap". Then, because it's a method-local reference, the actual reference will be on the stack. By "the" stack, we mean the native thread stack (i.e. the same stack that a local variable in C would be allocated on) in the case of Sun's VM at least, but I don't think that's actually a requirement (the JVM just has to have some abstract notion of "stack frames" that it allocates on each method call, be it from the native stack or not).
But... on modern VMs (with admittedly the possible exception of simpler embedded/mpbile VMs), there's really no such thing as "the" heap. In practice, there are various heap areas.
The simplest of these is typically almost like a "mini stack", designed to be quick to allocate for objects that won't hang around for long and can probably be de-allocated almost at once.
As mentioned by another poster, a highly optimised JVM could in principle allocate object data on the stack and there are definite proposals for this. Although, as also mentioned in one of the references, a criticism of this is that the fast "eden" heap is almost like a stack anyway (just not "the" stack).