Re: Short-lived Objects - good or bad?

My own position (and also what I've gathered in workshops
before my SCJP and also from reading this newsgroup) was,
that generally it is better to allocate and drop objects
inside a loop, rather than allocate them before the loop
and re-initialize them each iteration. (That is due to how
GC works with separating short-living objects from longer-
living objects, which could otoh be also seen as a non-
guaranteed implementation detail, afterall)
There are of course exceptions, where *re*-initialization
cost would be considerably lower than first initialization,
e.g. where only a fraction of the object's state would vary
with each iteration. I dare to say that these were quite rare
in the reviewed code.

Just recently I was confronted with comments from a reviewer,
(with whom I'm not in the position for arguing directly) who
criticized the code for (among other stuff) its rather frequent
use of new inside loops.

Judging from other comments, it doesn't look like he really
analyzed each particular situation, but more likely made a
general statement, and counted actual occurrances of certain
patterns. I could of course be wrong here.

Did I miss out some paradigm shift away from short-lived objects
recently?

Another example of different judgement is "try-catch inside
loops" (which I'd have seen as dictated from algorithm logic,
rather than either a good or bad choice).