[ https://issues.apache.org/jira/browse/LOG4J2-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17353734#comment-17353734 ]
Gary D. Gregory edited comment on LOG4J2-3100 at 5/29/21, 11:31 AM: -------------------------------------------------------------------- I agree with [~vy]. It's better to provide API stability IMO. As soon as you allow a type to be extended you are locked in to provide compatibility for not just public method but also protected methods and variables. Recall that unless your design use case defines a true "is a kind of" relationship for a subtype, subclassing becomes a reuse convenience hack where composition would be appropriate. was (Author: garydgregory): I agree with [~vy]. It's better to provide API stability IMO. As soon as you allow a type to be extended you are locked in to provide compatibility for not just public method but also protected methods and variables. Recall that unless your design use case defines a true "is a kind of" relationship for subtype, subclassing becomes a reuse convenience hack where composition would be appropriate. > log4j2 lots of final class, forbid extend class, why log4j allow extend > class but log4j2 not? > ----------------------------------------------------------------------------------------------- > > Key: LOG4J2-3100 > URL: https://issues.apache.org/jira/browse/LOG4J2-3100 > Project: Log4j 2 > Issue Type: Question > Reporter: hzwwe > Assignee: Volkan Yazici > Priority: Trivial > > RollingFileAppender > PatternLayout > etc.... > all are final class -- This message was sent by Atlassian Jira (v8.3.4#803005)