[
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)
