As if "final" isn't bad enough, some people would like to make it the default:

I’ll say it one more time: final should be the default. Java’s mistake was not that it allowed classes to be final. It was making final a keyword you had to explicitly request rather than making finality the default and adding a subclassable keyword to change the default for those few classes that genuinely need to be nonfinal. The lack of finality has created a huge, brittle, dangerously breakable infrastructure in the world of Java class libraries.

Umm, sure. Because every library I've ever used was designed specifically with my needs in mind, and I've never, ever had to extend anything.

*Cough*

That must have been something coming up there. I guess the BS meter just went to infinity, and I couldn't take it anymore. He goes on:

One final point: final is the safe, conservative choice. Should you mark a class or method final, and later discover a need to subclass/override it, you can remove the finality without breaking anyone’s code. You cannot go the other way. Once you’ve published a class that’s non-final you have to consider the possibility that someone, somewhere is subclassing it. Marking it final now risks breaking people’s running code and working systems.

It's safe, just like a straitjacket. With all possible movement impossible, how much can you do? It's not about breaking someone else's code anyway. When I get a library from a vendor, I don't expect perfection - I expect a best effort, given the knowledge the engineers had at the time. I fully expect to have to subclass in some places, to delegate in others, and to override methods in subclasses in some cases. Heck, I'm using smalltalk, so my amp goes to 11 over here - I may even change code in existing classes in the library. I'm sure that concept will make his head explode, but my goal is to empower the developer - not to break his wrists because he folded the napkins wrong.