Take the 2-minute tour ×

The purpose of this query is to compare one aspect of Java and C++, that has to do with the "new" operator.

Now, I know that in C++ there are two ways to create objects; with or without the "new" operator. In the absence of that operator, space is not allocated in the heap region, whereas, in its presence, space is allocated in the heap region.

What about Java? I notice that the "new" operator is used for creating every object. Even arrays are created with the "new" operator. Does it mean that in Java there is only one place for objects to exist in - that is, the heap region?


share|improve this question
In general, the same name for a keyword doesn't imply similarity -- there sometimes just is. –  Linuxios Sep 16 '12 at 5:40
What is the problem with accepting an answer? I saw your questions few excellent answers are given why are you hesitating to give credit for what they have tried? –  Dibya Sep 16 '12 at 5:46
Am I supposed to pick an answer? I didn't know. –  softwarelover Sep 16 '12 at 5:51
(I removed the C++ tag and made the title more refined, even if lengthy. Now, if the question was about C# -- which still uses new for Value Types which can avoid "stack allocation" -- the answers would be different as C# is not Java just as Java is not C++.) –  user166390 Sep 16 '12 at 5:52
Also, some objects can be created without new - Strings, and Auto-boxed primitives are two counter-examples I can think of. –  user166390 Sep 16 '12 at 5:58
show 2 more comments

3 Answers

up vote 3 down vote accepted

Yes, the new operator always allocates memory for the object on the heap. Unlike C++, objects in Java cannot be created on the stack.

share|improve this answer
The notion of the heap is implementation-specific, for the Virtual Machine Specification intentionally does not restrict storage options. –  oldrinb Sep 16 '12 at 5:58
+1 Would say instead "Unlike C++, there is no way in Java to say you want an object allocated on the stack" –  Peter Lawrey Sep 16 '12 at 9:14
Happy commenting in future. ;) –  Andrew Thompson Sep 20 '12 at 6:44
add comment

Local primitive types, and local references to object types, both take up "stack" memory, as do they both when passed as parameters to methods.

All objects themselves exist in the equivalent of a "heap".

share|improve this answer
@softwarelover the storage of Java objects is intentionally left unspecified by the Virtual Machine Specification; this is taken advantage of my VMs like HotSpot that use escape analysis to instead take advantage of stack allocation for objects :-) –  oldrinb Sep 16 '12 at 5:51
He's saying within any block (e.g., function body) exists some local variables. Whether they are primitives or allocated objects, they both have some presence on the stack: primitives are completely on the stack (e.g., a 4 byte int is 4 bytes on the stack). Allocated objects can be conveniently thought of as pointers on the stack; they take up space on the stack just like a pointer would, which is used to reference the actual object pointed to in memory (created using new). As @oldrinb points out, this may not be exactly what is happening, but it is effectively what is happening. –  pickypg Sep 16 '12 at 5:54
Thanks pickypg, now I understand what Alnitak said. I didn't read carefully.. –  softwarelover Sep 16 '12 at 6:02
@pickypg a fun fact is that the JVM operand stack uses a 32-bit width for its stack words. double and long are stored using two words. –  oldrinb Sep 16 '12 at 6:03
add comment

All Java objects (i.e. all things with a reference) are allocated in the heap1 from the perspective of the application and the application programmer2. Java does not support explicit allocation of objects on the stack. Object references can be stored both in heap nodes (i.e. class or instance fields) and stack frames (i.e. local variables, etc).

In fact, there are a few ways that first class Java objects can be created in Java that don't involve using the new keyword.

  • The { ... } array initializer syntax can be used in an array declaration without the new keyword.

  • A String literal involves the creation of a String object (at class load time).

  • The boxing conversion will (typically) create a new wrapper object without an explicit new or method call.

  • The reflective newInstance and similar methods create objects without an explicit new.

  • Under the hood, the implementation of Java serialization uses a special method in the Unsafe class to create objects without executing any declared constructor.

  • You can also create Java objects in native code using the JNI / JNA apis.

(There is a strong argument that the last two are "not Java", but they are worth mentioning anyway. And the String literal and auto-boxing cases involve Java code that uses new under the hood.)

1 - There can be more than one heap, though this is transparent to the application.

2 - The latest Hotspot JVMs have an experimental "escape analysis" feature that determines whether objects "escape" from the context in which they are created. Objects that don't escape could be safely allocated on the stack. Once again, this optimization is transparent to the application.

share|improve this answer
While this is good info, it doesn't answer the core question of "on the stack / on the heap". Add "regardless the objects are always created on the heap" and this would be the best answer. –  EdC Sep 16 '12 at 10:01
@EdC: Agreed with you! –  softwarelover Sep 16 '12 at 12:15
add comment

Your Answer


