1

As per this answer here

both java objects and primitives go on heap. So from the point of view of JVM, are objects and primitives similar except thaty objects take more space on the heap? In essence, are primitives nothing but 'light' objects?

trincot
  • 317,000
  • 35
  • 244
  • 286
Victor
  • 16,609
  • 71
  • 229
  • 409

3 Answers3

7

Java primitives are not "light objects". They are primitives. They fail as objects in two very significant ways: they cannot go into Collection objects and they do not have methods.

They also do not go on the heap, except as fields of an actual Java object. You cannot do new int. Note also that when you declare a local variable that is of a primitive type, the variable comes into existence. When you declare a local variable of an object type, all you get is a reference to an object, but it is set to null and no object of the declared type is allocated by simply declaring the variable.

Note that autoboxing blurs the distinction somewhat, but the distinction is definitely there.

Ted Hopp
  • 232,168
  • 48
  • 399
  • 521
  • "do not go on the heap, except as fields of an actual Java object". Even then one could argue that they don't go on the heap, they are just part of the struct representing the object (which happens to be in the heap). – Thilo Aug 04 '13 at 23:49
  • @Thilo - I was trying to say that a Java primitive (in isolation) cannot be allocated from the heap, while also trying to avoid suggesting that a primitive field of an object is somehow allocated from different memory than the object itself (when the object is allocated). – Ted Hopp Aug 04 '13 at 23:53
  • 2
    That's a good phrase: A primitive field is stored as part of the object it contains. Whether that is on the heap (which in current Java it always happens to be) or not is immaterial. As opposed to object fields, where only the reference is stored as part of the object, and the contents are separately allocated. – Thilo Aug 04 '13 at 23:56
  • Stored as part of the object that contains it. ;-) – chrylis -cautiouslyoptimistic- Aug 05 '13 at 00:34
1

There is a bit of confusion here. The question you're linking to in your question says that primitives inside an object can be in the heap. Primitives can't be in the heap by themselves.

You can't have an int referenced like an object, they are accessed directly without being "dereferenced".

morgano
  • 17,210
  • 10
  • 45
  • 56
1

You're extrapolating the fact that primitives could go in heap (as part of other objects) to conclude they could be light-weight objects. A set of primitives make up the state of an Object. They're not objects by themselves.

Primitives just have a value. They don't have a state and behaviour like Objects do. They don't exhibit inheritance, polymorphism etc. They don't behave like entities but like their attributes.

Ravi K Thapliyal
  • 51,095
  • 9
  • 76
  • 89
  • 2
    A primitive does, in fact, have a state: its current value. – Ted Hopp Aug 05 '13 at 00:03
  • @TedHopp, there's a difference in degree there. One would hardly say, "what's the state of int i when the loop exits?" or, "the application value has gone corrupt." They aren't interchangeable and are different semantically. – Ravi K Thapliyal Aug 05 '13 at 00:13
  • I don't think there's any semantic difference at all. After all, the state of an object is nothing more than the collection of current values (states) of its fields. (This includes the states of all referenced objects. One can debate whether `transient` fields are included, but the principle is the same.) A primitive field can certainly be in a corrupt state. If code was in the middle of, say, swapping bytes around while also doing some other work, and was interrupted (say, by an exception), the primitive can reasonably be said to then be in a corrupted state. – Ted Hopp Aug 05 '13 at 00:28
  • @TedHopp, I agree on a set of values making up a state. That's part of my answer too. I think of values as more of individual elements that make up the state of some entity. – Ravi K Thapliyal Aug 05 '13 at 00:35