4

In C++, we can also create objects on the stack, as we often do. Why did they decide to avoid this feature in Java?

sodaluv
  • 449
  • 2
  • 9
  • 22
  • The "stack" & "heap" aren't terms as far as C++ is concerned. It's an implementation detail. – StoryTeller - Unslander Monica Jul 12 '16 at 08:49
  • @StoryTeller, interesting. Please, can you be more specific?Even though, you don't believe answering questions completely. – sodaluv Jul 12 '16 at 08:54
  • 1
    [This](http://stackoverflow.com/questions/1350819/c-free-store-vs-heap) is one explanation of the difference. Another thing to remember is that c++ doesn't mention a stack, it mentions "automatic storage duration". That means variables are tied in lifetime to a scope, how the scope is implemented is immaterial (a call stack here is the implementation detail). – StoryTeller - Unslander Monica Jul 12 '16 at 08:57
  • 1
    This is important, because when C++ finally introduces co-routines, the wording of the standard will not change. The scope will have to be managed dynamically, but the storage duration of the variables is still the same. – StoryTeller - Unslander Monica Jul 12 '16 at 08:59
  • @StoryTeller, Actually, good point. – sodaluv Jul 12 '16 at 09:02

1 Answers1

9

Why did they decided to avoid this feature in Java?

It's simpler. Java doesn't say "Why not add it?" The Java designers usually waits until they really have to add a feature before they do it. (Tends to be a bit late IMHO, though perhaps this is a good thing in some ways) This means there is a minimum of features to learn and understand to be an expert in Java.

One thing you don't have to worry about what happens to your object once your method returns. e.g. in Java you can do

static String str; // In Java str is a reference.

static void setS() {
    String x = "Hello";
    str = x;  // x and str are references to an object on the heap so no problem.
    // if str was now a reference to an object on the stack, 
    // you could have a corruption issue.
}

However, with Escape Analysis the JVM can "unpack" an object which is notionally on the heap, onto the stack so that no heap allocation actually occurs. The downside of the current implementation is there is no way to force the JVM (or even hint) for it to do this.

On the plus side, it is one less thing you have to worry about in Java.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • Why didn't i think about this earlier? Perfect, thanks. – sodaluv Jul 12 '16 at 08:49
  • @Caleb probably because it's not terribly obvious IMHO. – Peter Lawrey Jul 12 '16 at 08:51
  • 3
    You wouldn't have to worry in C++ either, because `s` would be a copy of `x`. And it isn't clear to me that it is "simpler" than value semantics. It certainly simplifies classic polymorphism. But there are downsides to referential semantics. – juanchopanza Jul 12 '16 at 09:06
  • @juanchopanza In Java `s` and `x` are references. If `s` was a reference, it wouldbe a problem. – Peter Lawrey Jul 12 '16 at 09:08
  • 4
    @PeterLawrey I know they are references in Java. But "you don't have to worry about..." it isn't clear in which scenario you *would* have to worry. – juanchopanza Jul 12 '16 at 09:09
  • 1
    @juanchopanza thank you for the comment, I have updated my answer to clarify. – Peter Lawrey Jul 12 '16 at 09:09
  • You might want to emphasize "usually", though whether that's (still) true is debatable. – Deduplicator Jul 12 '16 at 09:14
  • 1
    @Deduplicator I did think that with Java 8, but when you look at Java 9, there isn't much they are adding which is terribly new/cool/fun, and it's unclear how much Oracle is investing in JavaEE, rather it is trying to get into the Cloud. Java 9 is adding a REPL which is might be better than Beanshell which more than ten years old. – Peter Lawrey Jul 12 '16 at 09:20