Latency and unpredictability of garbage collection is a severe problem for any UI, and even web/database backends. Your Cassandra node can run fine for a week and then fragment its heap and go into 20 second stop the world GC, causing user requests to time out. Silly things like allocating large byte arrays and dolling out offsets and length for individual uses are done to avoid big GC pauses. It still doesn't always work, because there are a lot of VM versions and user access patterns shift over time.
For all that, memory leaks are no less common than in C++ and non-memory resource leaks are horrendous. In C++, your object's destructor is cleanly called when the object is deleted or goes out of scope. That will take care of also calling destructors on anything encapsulated, which can then close files and unregister listeners. In Java, the while 100MB object hierarchy will be still consuming heap because some leaf node's close method was not called and it's a button click listener with an indirect link back to root.
A grown up language can support stack based and encapsulated object instances that don't have to be GCed and have predictable destruction time. Large and provably acyclical objects like bitmaps can also be reference counting. In practice, GC pauses are no better than crashes, so in real life even unsafe explicit delete makes sense in many cases.