I added @InternalApi to all the classes that were marked “consider this class private”. As for the plugins, yes, now that we’ve got that stabilized, I think that makes sense to keep stable, too. — Matt Sicker
> On Nov 5, 2023, at 16:22, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > > >> On Nov 5, 2023, at 2:58 PM, Matt Sicker <m...@musigma.org> wrote: > >> I’ve suggested that we annotate code around API compatibility guarantees, >> and we are using @InternalApi in main to mark things that shouldn’t be used >> as stable code (even if it’s unlikely to change over time). >> > > Please be careful of your usage of the term “API”. Log4j-API is one thing. > Very little in it should be private but there is some stuff. We have done a > decent job of adding comments of “consider this priviate” but using > annotations and any tooling we can to enforce that would greatly help. > > As for the other modules, Log4j-Plugins obviously has a publicly exposed API. > That was intentional as my hope is that eventually Log4j-Plugins could become > a general use framework, not specific to Log4j. Log4j-Core is where the real > meat of this is. If we wanted to be really clear we could have split > log4j-core into log4j-core-api and log4j-core-impl but using JPMS and > annotations should be enough. > > Ralph >
