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.

Make it opt out/default behavior.

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

He also suggests that even with process isolation in the application layer, the database is likely not going to be isolated and you'll be breached anyway.

The qmail architecture would likely be very inefficient with 100M+ users.

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.

That's right, but the OP did mention how that issue is addressed in c/c++:

> so you can't use straightforward NoExecute bits (provided by hardware and supported by OS loaders to disallow calling into dynamically allocated memory

Buffer overflow