BACKGROUND:
Code analyzers like CheckStyle contain special "design for extension" rule. It enforces really special class design approach. As form me it is really controversial thing. Here was good illustration of this design approach. The key is you protect super class from modification leaving only small 'holes'. or you make your classes final. Definitely good for some cases of secure library design.
From the other hand we have Java 'bean' POJO style where you hide all your data members and provide only public (or protected) accessors (getters) and mutators (setters). Having real life beans this makes them almost impossible to be extended as by my opinion. As far as I understand the only way is to aggregate bean and re-implement all needed accessors / mutators. But this seriously lowers things ilke performance.
I see SONAR dropped "design for extension" rule from default profiles in 2011. Please pay attention one person have returned this year to recheck it ;-).
QUESTION:
So I plan to drop "design for extension" rule from my Sonar quality profile primarily because it makes POJO re-usage much harder but I have some doubt if I missed some approach that allows usable inheritance of the classes with accessors / mutators keeping good security against descendants. Is there any standard approach that could change my mind? Can this conflict be resolved with "design for extension" approach adopted?
Sorry, no 10 years in Java so I could really miss something massive. ;-)
I would be pragmatic, and ask who the consumers of your code are. If this is some framework for use in by a wide (public?) audience then you may wish to consider carefully your extension points. Partly, to express your intent, partly to protect the parts that shouldn't change. However, if this is for use internally with a smaller audience, then you could all agree to be a bit more relaxed.