As to the grandparent post -- just because I started with Java 1.0 doesn't mean I assume that the JVM hasn't changed. I've been redoing my tests with each Java release that came out to see if my old assumptions still applied.
I'm a professional programmer, not some kid hacking code in a basement.
I expect a professional Java programmer to know that "Raw object allocation is EXPENSIVE" is WRONG and OLD information: http://www.ibm.com/developerworks/java/library/j-jtp01274/index.html
"Performance advice often has a short shelf life; while it was once true that allocation was expensive, it is now no longer the case. In fact, it is downright cheap, and with a few very compute-intensive exceptions, performance considerations are generally no longer a good reason to avoid allocation. Sun estimates allocation costs at approximately ten machine instructions. That's pretty much free -- certainly no reason to complicate the structure of your program or incur additional maintenance risks for the sake of eliminating a few object creations.
Of course, allocation is only half the story -- most objects that are allocated are eventually garbage collected, which also has costs. But there's good news there, too. The vast majority of objects in most Java applications become garbage before the next collection. The cost of a minor garbage collection is proportional to the number of live objects in the young generation, not the number of objects allocated since the last collection. Because so few young generation objects survive to the next collection, the amortized cost of collection per allocation is fairly small (and can be made even smaller by simply increasing the heap size, subject to the availability of enough memory)."
There are cases where it makes sense to use your own allocator, generally for big objects, but the blanket advice you gave will cause more harm than good.