Thanks again.

That should read:

I feel that unless a member needs to be non-final, it should be final.

Another technique is to use stateful objects that never escape the stack. There is no concurrency issues with this and in fact, future versions of Java will (if all goes well) actually create such Objects on the stack or even extract their members onto the stack.

But again, I completely agree with reducting state to the absolute minimum. If you do so, it will be much easier to refactor code to be threadsafe if needed in the future.

John–Yes but those numbers are for a page performing well. The poorly performing page is usually from the db. It is hard to spend a lot of time in a JSP and not notice it.

Thomas–you are totally correct. Thank you for catching that. The Goetz book I mentioned before gives the conditions for immutability nicely, stating that an object is immutable if
1. Its state cannot be modified after construction.
2. All its fields are final and
3. It is properly constructed (the this reference does not escape during construction).

编程的六个原则…

Using a profiler, I found that only ten percent of the total time to display a JSP in my J2EE application was spent querying the database and building persistent objects. The other 90% was spent on in-memory operations required to render the page. This is a commercial application that was built using industry best practices by ten of the best software developers I have ever worked with.

I have seen bad developers waste a lot of resources optimizing the wrong code. The 7th principle - forget everything you think you know about performance bottlenecks.