Do you want Java to do deep packet inspection on all network traffic?
Because Java supports naked sockets [1], so that is what you would have to do to block the network traffic from containing .class files.
(Or remove the capability of real networking. I suppose we can agree that a language which doesn't support networking is quite limited in its use nowadays?)
I don't have a 100% settled opinion about what the JVM design should look like, so I'm not fully aggreeing with the parent poster. However, I don't think you're being fair to the spirit of the complaint. There's a difference between two scenarios:
1. You can write a raw socket, pull a class file, put it in the right place, and load it using classloaders (assuming they don't want to abolish dynamic class-loading)
and
2. The language has a conventional way of loading arbitrary classes over the network using the standard library.
Any turing complete language can download and execute code. Even if the language doesn't support it natively, you can write an interpreter that acts on some code/bytecode. However, some languages support hot-loading code over the network in a straightforward way, while others force you to do all the work yourself (with attendant limitations). In effect, those languages require you to take the gun, check that it is loaded, and very carefully point it at your own foot.
Because Java supports naked sockets [1], so that is what you would have to do to block the network traffic from containing .class files.
(Or remove the capability of real networking. I suppose we can agree that a language which doesn't support networking is quite limited in its use nowadays?)
[1] https://docs.oracle.com/en/java/javase/16/docs/api/java.base...