Garbage Collection

I read the magazine Software Test and Performance. This is because formal testing plays a large role in the project I work on. The development team does unit testing. An internal team does integration, functional, and regression testing. A customer team conducts software acceptance testing. I need to keep up with the world of testing.

A recent article in the magazine talked about the Java environment. Specifically they referred to it as managed. To me that sounds like Dot Net. They were referring to Garbage Collection. And they thought that it was a danger.

Yes the garbage collector looks after memory in the Java environment. However Java programmers just assume the garbage collector will do its job. Objects which go out of scope are supposed to be cleaned up. However if the garbage collector does not know about an object, or can't determine that we are done with it, the memory will remain unclaimed.

Some industry experts were consulted. One of them said that inefficient code leads to memory problems, even in Java. The recommendation was to be proactive in testing Java applications. The use of automation in testing was also suggested. It was stressed that any Test Driven Development cover all paths in the software.

Here I thought the garbage collection idea was a nice one. I come from the land of C and C++. It is a lot of work to manually control the allocation and freeing of memory. Java is actually a fresh perspective on memory reallocation. But with most things, you can get in trouble if something or someone other than you takes care of the hard tasks. I have learned that by dealing with frameworks for a number of years.