A famous error that sprouted out of the Java Virtual Machine 1.0 and some 1.1 versions. Not to be confused with an Exception, which is generate from applications tripping on the soap and breaking their hip, an Error relates a system resource bursting into flames. In the case of this Error, the issue is with the JVM keeping the kids out of the memory cookie jar.

With the advent J2SDK (Java2 Software Development Kit) the problem was canned. What problem you ask excitedly? Well, Java is for lazy smucks that do not like to clean house, hence it has garabage collector for its memory spaces. This means a Java program can stomp around to its heart's contain and at the end of its execution, the garabage collector will step in free up the unused memeory. . . in theory. Trouble starts when Java programs refuse to be reaped by the garbage collector.

A mult-threaded application would run flawlessly numerous times, but slowly but surely, it would creep to a halt and kick out the loveable java.lang.OutOfMemoryError. The problem stems from Threads motherly nature. Even though a program gotten tired of living and longs for death, and even the Thread has been retired, the Thread refuses to let go. The Threads steadfast denial of reality keeps the garabage collector from blasting the Thread & friends into the void. Slowly but surely memory gets filled up by overbeaing matural Threads.

Luckly, this is a moot point now. *knock on wood* The lastest version of J2SE ensures that Threads long for death and the garabage collector has been buffed up, ready to drop kick surley memory stealers.

See Also: java.lang.GarabageCllector.onStrike() and Java's new class, java.lang.cops.strikeBuster()