Here's a performance engineering truth that was known even before Java was a twinkle in Sun's eye: do not assume that you, as a programmer, can predict the performance characteristics of your code. Software has been too complex to do that properly for at least two decades. Avoid ugly precautions against non-existant issues, write code as elegantly as you can, and be very grudging about sacrificing any elegance for performance, doing so only where usage-realistic profiling has proved it to be necessary.

"Premature optimization is the root of all evil"

Is this an advert for Tapestry, or one of a hundred other frameworks, named because you have to stitch it together yourself, and it's like a medieval war getting it working.

Still at least you can't criticise their naming conventions. You can't say you weren't given clues about what you were getting.

Take Spring, for instance, it's clear they're trying to make money by fooling people into thinking it means "Spring into action" when in fact it's equivalent to Hibernate which is more honest because it's explicit that anything you write in it, won't wake up until after the thaw.

There's no real argument you can place against Java. You point out that one library is crap, and they say, well you should be using any of another dozen different freeware installations, and when something goes wrong, they all start salivating because "It's a great challenge that there's noone to ring, and I'll just ask the brotherhood if any of those has come across this feature."

It's like feminism, or religion. No two people have the same opinion of what it should be, other than whatever you want to do, it will be the opposite. No two people practice the same ideology, and and whatever arguments you propose against any of the flaws, they say, "It's not meant to be like that."

I don't know why Java's even got version numbers, they should just name them after rivers or something. Or better still, how many more machines you're going to have to buy to run the ridiculous middleware frameworks.

Meanwhile the Project Manager's crying in my office.

Concerning performance of contended synchronization:

If you're using Java 5, and you're considering hand-coding a synchronized data structure as opposed to using something directly from the concurrency framework, note that the explicit synchronization provided by the Lock class is implemented differently (native "testandset" and "testandswap" operations) than it's implemented with the implicit "synchronized" keyword, and is even faster. In JDK 1.6, those improvements were put into the implicit synchronized code.

Much of this is described in "Java Concurrency in Practice".