The JVM community tends to prefer pure Java implementations of everything, rather than using existing C libraries like Python and Ruby. Some may see this as a bad thing, but it definitely has its benefits. One particularly relevant benefit in the context of this article is that the amount of code that can leak memory, in the conventional sense, is dramatically reduced. I suppose the same thing is happening in the Node.js ecosystem, though I don't recall if Node uses native code to parse XML.
Ironically, C memory leaks are often significantly easier to debug than Java ones. In C, libraries like libumem basically do postmortem GC that can point straight to the leaking callstack (depending on how much debug info you can tolerate).
In GC'd languages, there's no real way for the VM to identify a leak.
If you don't mind potentially slow code, that's a fine thing. Once you've measured and discovered that you're losing out on a lot of performance, it's worth evaluating whether the risk of leaks can be baked away via careful testing, which doesn't appear to have been done at all in the library used in this blog post.
If you say so. That's not what I've observed, especially if you're talking about code where Python is the glue and all the heavy lifting is done in C or C++.
I am comparing Java to Python. Not Java to Python code wrapping C++ code. Because in that case, we would be really comparing Java to C++ code. Which I am happy to do, but not what I did.
