The linked reference I removed does not mention object pools at all. The following article in the series (https://www.ibm.com/developerworks/java/library/j-jtp01274/index.html?ca=drs-) does not say to *never* use object pooling in Java
Some publications do not recommend using object pooling with certain languages, such as [[Java (programming language)|Java]], especially for objects that only use memory and hold no external resources{{which|date=August 2020}}. Opponents usually say that object allocation is relatively fast in modern languages with [[Garbage collection (computer science)|garbage collectors]]; while the operator <refcode>new</code>{{citewebneeds only ten instructions, the classic <code>new</code> - <code>delete</code> pair found in pooling designs requires hundreds of them as it does more complex work. Also, most garbage collectors scan "live" object references, and not the memory that these objects use for their content. This means that any number of "dead" objects without references can be discarded with little cost. In contrast, keeping a large number of "live" but unused objects increases the duration of garbage collection.<ref name="urban" />
| url = http://www.ibm.com/
| title = Java theory and practice: Garbage collection in the HotSpot JVM
}}</ref> Opponents usually say that object allocation is relatively fast in modern languages with [[Garbage collection (computer science)|garbage collectors]]; while the operator <code>new</code> needs only ten instructions, the classic <code>new</code> - <code>delete</code> pair found in pooling designs requires hundreds of them as it does more complex work. Also, most garbage collectors scan "live" object references, and not the memory that these objects use for their content. This means that any number of "dead" objects without references can be discarded with little cost. In contrast, keeping a large number of "live" but unused objects increases the duration of garbage collection.<ref name="urban" />