People really are funny
I was sitting here thinking about the status of a project I'm working on and I had to giggle to myself a little. Now I've written in the past about the company that provides the basic framework/infrastructure and how it's not the most incredible piece of engineering I've ever seen, but today's got to be a new high (or low) point in the saga of this project.
We have been facing a real problem with stability that, in my opinion,
has been brought on by the lack of careful development design that Java seems to breed. Not that I've got anything against Java as a language, but whenever you have a language that tries to do so much for you, you run into folks that this this is some sort of magic Genie that will take care of a lot of other things as well.
But I suppose Garbage Collection is a good thing - if you understand the limits of technology. It's not perfect after all. Let's take the example of an event-driven system. A good design might be to have each event source capable of sending one event through the system, and buffering up the others in some sort of compressed queue, until the handlers of the event are done with the one you've already sent. Then there's the magic Genie model that says "Hey, let's generate a new Event Object for each event and pass them on as they are generated." This is the incredibly bad design that Java so easily allows that I'm talking about.
On the surface, both seem the same. Both handle all events - one buffers them at the source, the other somewhere in the event processing loop. But the enormous difference is that the first one allows for such ideas as "too busy" while the other simply allows for excessive memory usage that will lead to crashes.
If you don't exercise some level of common sense in the insertion of events into the stream, you can't be upset when the stream can't keep up with the flow of events - and the Garbase Collector can't keep up with disposing of all these created objects. Yes, it should in a perfect world, but this isn't, so it can't. With one Keyboard Event Object (say) that you reuse again and again for the different events, you don't have a problem with excessive memory usage. Also, in the Keyboard Event Filler you can say "OK, I've got 50 keyboard events in my buffer - that's enough, throw the rest out." or something similar. In any case, you can easily control the number of events since you're controlling them at the source. It's this kind of systems thinking that I'm seeing so completly absent in so many Java development projects these days.
C, Obj-C, C++ - they all made it hard to allocate and free memory and objects so you were pretty darn careful about what you created, where you passed it around and who freed it. Yes, this lead to memory leaks and this, in turn, lead to memory profilers. But the problem of
over-generation of objects seems to lie clearly at the feet of Java as it makes it too easy to create without any knowledge or care about the consequences, and lifetimes of these created objects.
In some ways, in the hands of good developers, Java's Garbage Collection is a good thing. But it doesn't absolve you from thinking that it's not magic. And that's where you get into all the trouble. In this regard, it'd be better to write in a little more complex a language just to force all the developers to think before writing.