Thank you for your feedback.
What you wrote about Java and C++ in terms of performance is simply wrong, these are just prejudices.
I really didn't want to go into discussions about Java vs other programming languages -there's already enough information to find on that elsewhere. I merely wanted to help people that are (planning to) write games in Java with things I learned along the way.
Objects pooling is often inefficient since Java 1.4 except in a few very particular cases
Agreed, you only need to consider pooling objects once you have problems with garbage-collector-stutters in your game. And even then, you probably only need to implement pooling in a hand full of methods to solve these issues.
I get excellent performances without using Java 1.7 try construct.
We use the Java 1.7 try construct purely for convenience, it makes sure that once the temp object goes out of scope its gets returned to the pool (instead of manually calling pool.push()). This is especially useful when you have multiple return statements within the scope of the temp object.
What you wrote about direct NIO buffers is very incomplete, you must release the native memory they use by yourself if you don't run out of memory on the Java heap, not on the native heap, I already wrote about that in my blog. Moreover, I modified Ardor3D so that you can free the memory allocated by this kind of buffers when used in VBOs in the renderer, you can simply override the method deleteVBOs(final AbstractBufferData<?> buffer) and call it between levels for example.
Well that is all a bit out of scope of the article. The only point I was trying to make is that you need to be more careful with Directbuffers in Java than with ordinary objects; garbage collecting them will lead to stutters in your game a whole lot sooner than with normal Java objects (and they are harder to find with the Java Visual VM as well).