>>> > I think this is a worthy purpose nevertheless and feel very strongly that > we should keep them - I don't see the harm.... > > BTW, I could argue the same case against *InitializingBean* and > *DisposableBean* in view of *@PostConstruct* and *@PreDispose*, but I still > think they are very useful. >
>>> Yeah, but that's historical. InitializingBean and PostConstruct were >> written before annotations were added to java ... Still, if we take the functionality criterion at its literal interpretation, these interfaces should have been phased out at least 3 major versions ago. My point, though, is that we should look at our code quality under the 80-20 principle. I believe we are way over 80% quality in our code and are starting to debate the last 5% - which bring us to these long discussions about code structure philosophy, where it is natural to have differences of opinion. IMO, if we seem to agree on the 95%, let's agree to disagree on the remaining 5% and unless harmful anti-patterns or extremely bad code is is involved let's not re-factor un-necessarily if someone (myself in this case) seems to have such reservations about it. In this context, I had reservations about reverting the fact that a CommandFactory is a NamedResource (which I think is very useful for future features I had in mind...) or the elimination of the anonymous unmodifiable class instantiations, but in the interest of avoiding these "5% discussions" I chose not to make an issue of it (live and let live). I am sorry I cannot provide more decisive arguments against the proposed re-factoring than what I have already presented - ones that you would find more compelling. As you can see I feel very strongly that it would not be in the best interest of the code to execute these specific *XXXHolder *removals, and all I can say is that I find them useful (which I am aware you disagree...) and unless you feel very strongly that they are harmful, we should leave them in.
