Gary has suggested that Log4j 3.x should be able to break binary compatibility since it is a new major version and somehow should be able to coexist side by side with Log4j 2. I am not really sure where he got that idea but I am going to try to explain why that is not workable.
First, to have both Log4j 2.x and 3.x able to coexist they would need to have separate packages, presumably by appending a “3” all over the place as Commons has done with its projects. We would then have to change all the artifact ids to include the “3”. This would be a lot of work. So lets assume we do that. What next? If a user says they have Logback and Log4j both in their project what is our advice? We tell them to use the SLF4J bridge to route everything to Log4j and remove the Logback jar. Why do we do this? Because no one wants to logging configuration files and having multiple logging systems writing to the same locations is asking for trouble. So to make this work we would need to create a bridge from Log4j 2.x to Log4j 3.x. This would mean creating a bridge that is a clone of 2.x but binds with 3.x. Doesn’t that seem silly when we can just keep the 3.x API compatible with 2.x? Next comes the problem of configuration files. Both Log4j 2.x and 3.x use log4j2.xml. Changing log4j2.xml (or yaml, json, properties) to log4j3.xml would impact lots of users. But the contents of the file wouldn’t have changed - we haven’t changed anything that affects the configuration format in 3.x So this change would only exist so you could tell which configuration was for Log4j 2.x and which was for 3.x if they are both present. So lets assume we leave it as log4j2.xml. This means if both are present that they both will find the same file and try to use it. Now we are back to the same problem of having two logging systems trying to write to the same destinations. That is a mess. So while repackaging might work for Commons projects it will cause nothing but problems for Log4j and users would hate us for it. I know I would hate us for it since I would have to deal with it in my own projects. So the bottom line is that we have to maintain compatibility between the releases. But I am sure that some of the classes we removed will not break compatibility. We just need to analyze what was removed and add back those that will affect users. Ralph
