This is pretty normal for compiled languages like C, C++, and Rust; the linker will throw out functions and classes that aren't used. In Java it's a bit different, because the compiler doesn't know if some code is using reflection to talk to some other code, so it can't safely throw away stuff that isn't directly referenced. Even then, tools like ProGuard can help you trim out code you don't use, but I don't think they're used all that often outside of mobile.

But the log4j thing really isn't in the same class because it's not really "code that wasn't used". It's code that probably users didn't expect was there, and if they knew would probably not want used, but it's there, and the proper functioning of the library included that code path that allowed for JNDI interpolation. Whether or not that code is really "needed" is not something the compiler can really figure out, at least not without teaching the compiler that very very very specific thing (which would be madness). And even then, let's say you bizarrely wanted to be able to do things very much like what the log4j exploits do, there's no way the compiler (or even some kind of specific purpose-built code scanner) can know whether or not some string that might be supplied by a user in the future is going to trigger this JNDI interpolation code.