3 ms·

The risk of memory problems don't disappear because of any form of GC. The problems are just different, and leaks are still quite possible.

• gozur88 10y ago
  They're possible, but not nearly as common. Back when I was coding C++ full time I spent most of my debugging time chasing down memory leaks and out-of-scope variables. Then in a decade of Java programming I think I had one memory leak.
  • hellofunk 10y ago
    But that's a two-edged sword. Many Java developers, especially those recently out of school, who have never had a C or C++ background, think the GC is a magical blanket that takes care of everything, and as a consequence they don't have an intuitive grasp of the true costs of memory. They just throw things around like it's no big deal. I've interacted with a lot of C++ developers who were hired to rewrite large Java applications in C++ for performance reasons, when really Java could have handled it if only the developers understood memory better. GC is an abstraction that can work well but can also interfere with how a developer thinks.
    • pjmlp 10y ago
      > I've interacted with a lot of C++ developers who were hired to rewrite large Java applications in C++ for performance reasons, when really Java could have handled it if only the developers understood memory better. Yep, this is a big issue. Another good example is copying arrays of primitive types with for loops instead of using intrisics like System.arrayCopy(). Or using lists instead of arrays. Sure there are many situations where there is no another way other than step out of the JVM into C++, but many could be avoided with better code as well.