As with code generation, it is fairly common to see false optimizations in Java applications, implemented with the belief that they will assist the garbage collector. Again, premature optimization is the root of all evil. At the Java level there is really very little to be known about how the GC will treat the program. The general sin is believing that the garbage collector will always behave in a certain way and try to manipulate it.
We have already discussed the case of System.gc that is not required to do anything at all, or might do a full-heap-GC stopping the world every time, or anything in between.
Another false optimization is different types of object pooling. Keeping a pool of objects alive and reusing them, instead of allocating new objects, is often believed to increase garbage collection performance. But not only does this add complexity to the Java application, it is also easy to get wrong. Using the java.lang.ref.Reference classes for caching or simply making sure to set object references to null as soon as they aren't needed anymore is usually sufficient enough for any modern garbage collector. Keeping objects alive longer than their natural lifespan can backfire. Generational GC usually takes care of temporary objects quickly, but if they are artificially kept alive and reused, they will eventually clog up the old space instead.
Frequently, people express the belief that there should be a static way to control all aspects of Java garbage collection, complete with free or delete operators as well as the ability to turn off and on garbage collection at arbitrary intervals. Another example is wishing for ways to get at and modify objects as native pointers directly in the JVM. Both these strategies would be extremely dangerous if introduced in Java, and successful usage would, in the authors' opinion, be very hard or impossible.
There are several advantages of automatic memory management, and some disadvantages, chief of which is non-determinism. JRockit Real Time has tried to provide good enough ways around this without the need for modifying an application or interfacing with the GC.
Note
We still recall with horror the "Java should have a free operator" discussion that swamped the entire HotSpot session at JavaOne 1999. The guy who started it raised his hand and opened up with the now classic line "Many of my friends are C++ programmers..."
In truth, a well-written Java program that uses all the allowed tricks in the book correctly, such as the correct java.lang.ref.Reference classes, and takes heed of the dynamic nature of Java, should run fine on a modern JVM. If a program has real-time needs that require further manipulation, maybe it shouldn't have been written in Java to begin with, but rather in a static language where the programmer's control over the memory system is more absolute.
Automatic memory management, while being a helpful tool that shortens development cycles and reduces program complexity, isn't a golden hammer that can be applied to all programmatic problems.