I don't know Java well, but at least in .NET it's possible to set a flag that disable execution of dynamically emitted code.

Obvs, you should do this on every box that accepts connections from the outside world.

Obvs, it's no easier to get people to do this in practice than it is to get people to quit using string formatting to get parameters into their SQL queries.

Or use other statically compiled languages instead.

Or at least use Java or O/S sandboxing features.

At least in the web-facing parts of their apps.

In any case, this requires some planning ahead, and a mindset different from "agile".

Maybe Java 9's AOT compilation can help in the process, but even if it could produce stand-alone programs, I think the dynamisms in Java code (reflection, annotations, dynamic class loaders) will make this infeasible for most code bases.

He is saying they should practice process isolation. Example architecture: https://cr.yp.to/qmail/guarantee.html

DEP and ASLR provide significant mitigation of the threat posed by this capability in statically-compiled languages, so it is definitely an issue that should be considered, along with others. Having said that, it is unlikely that there is any merely technical solution for the problem, which arises from the whole system being predicated on a falsehood - the assumed confidentiality of SSNs.

Programs in C and C++ can still execute data as code with buffer overflows. They're not a panacea either.

Buffer overflow