The Jan/Feb Java Magazine will go out next week. It's full of great Java stories, interviews and technical articles. It also includes a Fix This section; the idea of this section is challenging a Java developer's coding skills. It's a multiple-choice brainteaser that includes code and possible answers. The answer is provided in the next issue. For an example, check out Fix This in the Java Magazine premier issue.

We are looking for community submissions to Fix This. Do you have a good code brain teaser? Remember, you want tease your fellow devs, not stump them completely! If you have a submission, here's what you do: 

1. State the problem, including a short summary of the tool/technique, in about 75 words.

2. Send us the code snippet, with a short set-up so readers know what they are looking at (such as, "Consider the following piece of code to have database access within a Servlet.")

3. Provide four multiple-choice answers to the question, "What's the fix?"

4. Give us the answer, along with a brief explanation of why.

5. Tell us who you are (name, occupation, etc.)

6. Email the above to JAVAMAG_US at ORACLE.COM with "Fix This Submission" in the title.

Deadlines for Fix This for next two issues of Java Magazine are Dec. 12th and Jan. 15th. Bring It!

In a new article, part of the Developer Insight series, and titled “The Developer Insight Series, Part 6: Perspectives on Garbage Collection,” now up on otn/java, three leading Java developers offer insight into garbage collection.

Oracle Lab’s Ron Goldman notes, that, “Although automatic memory management has existed for more than 50 years, a lot of people still don't want it in their systems because it seems inelegant. It just strikes people as wrong – ‘It's my memory. I should be releasing it when I know it's no longer being used.’ Theoretically, that might be true, but in practice, programmers continue to forget to free up memory when they are done with it, or, even worse, try to free it up while it's still in use. The results? Buggy code that is apt to crash unexpectedly.”

Java Champion Kirk Pepperdine observes that, “Even though collection of very short-lived objects is almost free, high rates of object churn can still result in very inefficient GC numbers. Sometimes, the problem is simply that the Java Virtual Machine (JVM) doesn't have enough heap space. Monitoring GC activity will give you the hints you need for a successful heap-sizing exercise…”

And Oracle’s GC expert Tony Printesiz takes on eight myths about garbage collection, four of which are:

1. Reference counting GC will solve all my latency problems.
2. malloc and free will always perform better than GC.
3. Finalizers should be called promptly, as soon as objects become unreachable.
4. GC will eliminate all memory leaks.

The article provides a good context for developers to collect their thoughts about garbage. ;)

Read the complete article here.