I have a much more liberal view of the API. That is, if the class isn’t documented as private AND it can be reasonably used outside of Log4j then it is public. However, I would actually have to look at every class to see how much different it is from your list.
Ralph > On Jan 18, 2024, at 9:25 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi Ralph, > > On Thu, 18 Jan 2024 at 16:15, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> Note that LogManager has >> >> import org.apache.logging.log4j.simple.SimpleLoggerContextFactory; >> import org.apache.logging.log4j.spi.LoggerContext; >> import org.apache.logging.log4j.spi.LoggerContextFactory; >> import org.apache.logging.log4j.spi.LoggingSystem; >> import org.apache.logging.log4j.spi.Terminable; >> import org.apache.logging.log4j.status.StatusLogger; >> import org.apache.logging.log4j.util.StackLocatorUtil; >> import org.apache.logging.log4j.util.Strings; >> >> That would require users to have the SPI would it not? > > On Thu, 18 Jan 2024 at 16:20, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> And ThreadContext contains >> >> import org.apache.logging.log4j.message.ParameterizedMessage; >> import org.apache.logging.log4j.spi.LoggingSystem; >> import org.apache.logging.log4j.spi.LoggingSystemProperty; >> import org.apache.logging.log4j.spi.ReadOnlyThreadContextMap; >> import org.apache.logging.log4j.spi.ThreadContextMap; >> import org.apache.logging.log4j.spi.ThreadContextStack; >> import org.apache.logging.log4j.util.InternalApi; >> import org.apache.logging.log4j.util.Strings > > IMHO, the public API contains: > > 1. all the types in the `o.a.l.l` package, > 2. all the superclasses and superinterfaces of a type in the public > API (recursively), > 3. all the types that appear in the signature of public methods of a > type in the public API (recursively). > > Which mean the the Log4j API contains `o.a.l.l` and the following > types from other packages: > > org.apache.logging.log4j.message.EntryMessage > org.apache.logging.log4j.message.ExitMessage > org.apache.logging.log4j.message.FlowMessage > org.apache.logging.log4j.message.FlowMessageFactory > org.apache.logging.log4j.message.Message > org.apache.logging.log4j.message.MessageFactory > org.apache.logging.log4j.spi.LoggerContext > org.apache.logging.log4j.spi.ExtendedLogger > org.apache.logging.log4j.spi.LoggerContextFactory > org.apache.logging.log4j.spi.LoggerRegistry > org.apache.logging.log4j.spi.StandardLevel > org.apache.logging.log4j.spi.ReadOnlyThreadContextMap > org.apache.logging.log4j.util.BiConsumer > org.apache.logging.log4j.util.ReadOnlyStringMap > org.apache.logging.log4j.util.StringMap > org.apache.logging.log4j.util.StringBuilderFormattable > org.apache.logging.log4j.util.Supplier > org.apache.logging.log4j.util.TriConsumer > > Removing a method from any one of these can break user's code. Some of > these (certainly `Supplier`, but to a smaller extent `Message`, > `BiConsumer` and `TriConsumer`) are implemented by users, so even > adding an abstract method to those, will break user code. > > Piotr
