Having said that, developers should not "invoke garbage collector" or take any "care" to "not to have it". Good, bad, or indifferent, just let the GC do its job.
[ November 18, 2007: Message edited by: Henry Wong ]
However, it's really important to understand when objects become eligible for the GC. So, the most important thingyou can do as a developer to help yourself when it comes to memory management, is to be careful about freeing up references to objects so that the GC can, in fact, do its job
Don't think about setting variables to null just to encourage garbage collection. Learn to think about the life span an object needs and manage its scope appropriately. Local variables go away at the exit of a code block like a curly braces after an "if" or a loop or a method. If you find a block that you think is so long you'd like to null something out early, it's probably a hint to break up the block instead.
My most biggest worry is putting things in collections or a servlet session and forgetting about them. Again, it's careful scope and lifespan management, not thinking about GC.
Hope that helps!
[ November 19, 2007: Message edited by: Stan James ]
Well I was reading the JSR for real-time and reasonably early in the writing it is stated that there is a great deal of isolation between the theorists in R.T. vis-a-vis the practitioners, and that the gc is one area where attainability of Static Priority Bounds brings this contention to a investigatable design constraint. If we expose the gc calls to Java Beginners, and the calls are a reasonable area of concern for World-Class equipment makers, it may be that calls to gc.run() should be a null-stubb except for those ten people.
I therefore register an interest in being informed if those 10 people are theorists and not field engineers. There are known issues in Industrial Engineering and Management for which this knowledge is relevant. I have a Team Member degreed in the matter, for which I stubb my request here for later reference.
Well I was reading the JSR for real-time and reasonably early in the writing it is stated that there is a great deal of isolation between the theorists in R.T. vis-a-vis the practitioners, and that the gc is one area where attainability of Static Priority Bounds brings this contention to a investigatable design constraint.
Real Time Java is actually not a good basis for this debate. JSR 1 includes new types of memory models (immortal and scoped) whose purpose is to avoid GC altogether.
With scoped memory, you can write your program in such a way that the GC never has to run. In effect, you are writing your program with explicit directives that tells the JVM when the memory goes out of scope. The garbage collector knows what to collect, and when, without having to copy or mark/sweep.
IOWs, RT java is great for programmers who don't want to use the GC. The debate isn't whether GC is good or bad -- but more like the assumption is that it is bad, and here are the tools to avoid it.
IMHO, it is too early to tell if this is a good or bad thing. As I don't have a feel for the API, nor seen what the best practices to come from it yet.
[ November 25, 2007: Message edited by: Henry Wong ]
Well if it is bad in the opinion of people who can carry on a discussion like this, then it should not be in scope for beginners and the answer to the posters original question would be to not make any calls to gc and just let the JVM do it's work.