Probably the Textbook Example of Why Java Sucks
Published at 00:22 on 14 October 2023
Probably the textbook example of why Java sucks is the Log4Shell Bug in the log4j library.
It’s just a library and not part of the core Java language, but the core Java language really isn’t the problem. The problem is the dysfunctional culture that surrounds the language.
So the stock logging is both bloated and yet surprisingly limited in functionality, because that is the sort of code the Java community tends to produce. That creates the need for an expanded logging system. Since it fills a void, everyone uses it.
Since the community does not appreciate simplicity, what the hey, let’s stick a general-purpose templating language into the thing. The same community wrote that general-purpose templating language, so what the hey, let’s stick a shell escape with command-output substitution into the templating language. Both the general-purpose templating and the shell-escape feature of the templating are of course enabled by default, because what the hey, why not?
And suddenly, we have a logging library with a shell escape in it.
Just how bad this all is, is underscored by how it sat unnoticed for eight years before it started being exploited. That’s right, so few people actually used all this creeping feature-ism that it took nearly a decade for the vulnerability in it to be discovered!
Look, logging and templating are two different domains. Templating and launching commands in a subprocess are two different domains. A logging package has no business containing templating beyond approximately the String.format level. A templating package has no business containing general-purpose subprocess creation.
If you really have a need to generate a super-long, super-complex log message, long enough and complex enough to require a general-purpose templating system, you should probably rethink what you are doing. Log messages should be relatively short. Now, maybe your case is 1-in-1,000 to 1-in-1,000,000 special and there really is a good excuse for a long message. Maybe. Fine. Do it by hand. Pull in a templating library, use it to generate that message, and feed it to the logger. Don’t bloat up and complicate the code base for everyone else just because of your 1-in-1,000 (or more) special case.
Likewise, if you really need to substitute in the output from a system command into your template, use the subprocess-creation features of Java to run the command, collect its output, and feed it into the template. Again, a 1-in-1,000 (or more) special case, no need to clutter up the code base.
In short, it’s potentially dangerous. Make the programmer work a bit in order to do it. Not a whole lot (libraries should and do exist to make it easier), but a bit. Enough to get the programmer hopefully thinking about the consequences of the feature. Don’t just stick it in by default.
But who am I kidding? This is the Java community we are talking about. Too much can never be enough!