We've had some conversations about this off and on, though I don't think we've had any formal decision or discussion on it. For Log4j 3.x, we'd like to make it so that log4j-api, log4j-plugins, and log4j-core only require the java.base module with optional dependencies allowed for certain plumbing that can't otherwise be made required (e.g., optional OSGi dependency to allow for participating in bundle installation lifecycle events, optional LMAX Disruptor dependency for asynchronous loggers, that sort of thing).
With this idea, though, we lose support for all our configuration factories except for the builder API and the properties format (which uses said builder API) as XML is supported by the java.xml module while JSON and YAML are supported by an optional Jackson dependency for each. Many of us are unsatisfied with the properties configuration format as it's difficult to represent properties as a tree of nodes (as all the other configuration formats are tree-like), so this seems like a poor user experience to leave as the default. One idea proposed was to support JSON as a built-in configuration format. We have JSON parsing code present in JsonTemplateLayout which can be moved to either log4j-core or even log4j-api to support at least one basic structured format. If moved to the API, it can even be used for the PropertiesUtil enhancements proposed for configuring LoggerContext-specific options and other defaults. This JSON approach is probably the lightest way we can handle it without introducing a more complex parser. Any other ideas? Objections to doing something along these lines? The JSON parsing can be moved to log4j-api, log4j-plugins, or log4j-core, depending on how widely used the format will be here.
