Runtime classloaders expose a huge blast radius. That's unfortunately a Java language feature.

I guarantee Java would be vulnerable to the same category of errors even without runtime class loaders. Java puts a lot of emphasis on dependency injection, and has done this for a fairly long time. This takes the form of having classes pull dependencies themselves through some central registry over explicit construction.

It's arguably a symptom of a larger problem the ecosystem's sheer size.

As does dynamic linking, which is perfectly equivalent.

True, but that doesn’t make it better.

Well, there are 0 languages that don't support dynamic linking, so I don't see why we would single out Java.

Dynamic linking is not a language feature, it’s a feature of the operating system. If we’re talking about dynamic loading, there are plenty of languages that don’t support this natively, but only through its C bindings (e.g. Haskell).

Not only a feature but an idiom.

And made worse by static initializers being run when the class is loaded rather than when the class is first instantiated.

Class is loaded when it's first instantiated, unless you're explicitly loading it.

Most languages' built-in serialization has similar issues, e.g. Python pickle.

Even if this is true, most languages don’t use dynamic code loading as often as Java.

In what sense? In many popular languages (Perl/Python/Ruby/...) all code loading is dynamic. Java does have more of a built in RMI framework than most languages, but it's rarely used in modern code.

Pick a few random executables from your OS, check how many .dll or .so libraries do they dynamically link to.

For Python, JavaScript, Ruby, etc it's not even a question.

You practically cannot have the same vulnerability in C, because no one would bother implementing that kind of flexibility in C.

"Our language is harder to use than X, so it's safer because no-one will try to do certain things with it" is hardly a compelling defence.

It wasn't meant as a defence.

Another one that never saw the heyday of enterprise C code.

And if you disconnect your computer from the internet then it's safe from most remote attacks.

Was there not a flaw in the jndi api for ldap? log4j was just the entry point from what I understood.

No, JNDI is an API for accessing remote code. It stands for Java Naming and Directory Interface. Not supporting LDAP, the most common remote directory, would have been a flaw.

The flaw was in log4j's use of the library which allowed remotely connecting and executing code by default based on connection strings which were possibly user-entered.

Ok so JNDI's purpose is actually accessing remote code. You just have to not give it any untrusted data. It seems like a dangerous tool to use.