The problem is that we cannot just remove stuff from log4j-api now,
since that would break binary/source compatibility for existing users.
If I understand it correctly, due to the Java 9 modules, if we move
stuff from log4j-api to log4j-core we have to change package, right? And
we don't want regular users to need a compile dependency on log4j-core
anyway.
So I don't have an easy solution to fix it now, this is more a
retrospective to figure out why we ended up in this unfourtate
situation, and how do avoid that happening again in the future.
If I were to redesign Log4j 2 from scratch, I would consider not putting
this into log4j-api:
- All classes in org.apache.logging.log4j.message (only the interfaces
in API, except ReusableMessage and ThreadInformation)
- Most (or ideally all) stuff in org.apache.logging.log4j.spi
- The org.apache.logging.log4j.status package
- Most (or ideally all) stuff in org.apache.logging.log4j.util (since
they would not be needed anymore)
Some of it would go into log4j-core, some into a new log4j-spi module.
I think that the growing-out-of-bounds started with the garbage-free epic.
log4j-api.jar is now 249 KB, slf4j-api.jar is 41 KB.
On 2017-12-02 15:34, Remko Popma wrote:
Ok, you have some fair points there.
Main take-away for me is that if we want Log4j2's API to become ubiquitous
it needs to be at least painless for everyone.
Don't known about the "too much stuff" in log4j-api - bit vague and not
actionable.
