ramanathan1504 commented on PR #4128: URL: https://github.com/apache/logging-log4j2/pull/4128#issuecomment-4532291637
@ashr123 I completely understand where you are coming from regarding avoiding duplication of the literals. It makes sense that users can just define their own custom patterns in their own codebase. My main concern with the public enum wasn't just about user extensibility, but rather the long-term API lock-in for the Log4j project. When we introduce a new public type (like an Enum) into org.apache.logging.log4j.core, it becomes a permanent contract. If the Log4j architecture changes in the future (for example, completely refactoring the date engine in 3.x to rely purely on java.time objects rather than string mapping), deprecating and removing a public Enum breaks backward compatibility. The beauty of exposing public static final String constants is that the Java compiler inlines the strings directly into the user's compiled .class files. This means Log4j provides the convenience of the pattern without strictly binding the framework's runtime API to the Enum structure forever. Regarding the Supplier idea—that's a very interesting concept for extensibility! But I agree with you that it might be a bit too heavy/over-engineered just for this specific PR. Since introducing new public API types is ultimately an architectural decision, perhaps we can leave the PR as it is for now and see what the core maintainers (like @pkarwasz or @rgoers) prefer for the API surface? If they are comfortable committing to the public enum long-term, then your current approach is already perfectly clean! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
