This isn't because Log4j is doing anything wrong; this is because of increased scrutiny and eyeballs.
I do not envy the team having to work under this microscope :(
Conversation
Replying to
Certainly they’re not doing anything newly wrong, but in general having eval() in any logging library would have people aghast if it was newly created now. Sadly it slipped by unnoticed for years
1
9
Replying to
It was a deliberate "feature" they had to keep around for backwards compatibility :( they knew it was risky but previously didn't feel they could break it
4
11
It wasn't added that long ago and I don't think they had any intention of removing it. It was regarded as a useful feature and definitely wasn't just kept around for backwards compatibility.
log4j1 didn't have the feature and it's one of many things that got added with log4j2.
2
log4j1 was the defacto standard logging library in the Java ecosystem before the far simpler and more reasonable java.util.logging was added to the standard library. Since it was so broadly adopted, it still has far more users than log4j2 or the standard library logging module.
1
log4 was very complex and duplicates the functionality of system logging services like rsyslog. The original developer left Apache and continued their work with SLF4J and logback. Apache decided to continue using the valuable log4j brand name for a much more complex rewrite.
One of the features they added to their rewrite was this misguided in-band string interpolation. It would be a really bad idea even if it only supported variables, environment variables, etc. because it's in-band instead of using a properly separate format string with parameters.