First of all, what's been a pain wasn't modules (their encapsulation wasn't turned on until JDK 16; all JDKs before that had the exact same runtime access permi

First of all, what's been a pain wasn't modules (their encapsulation wasn't turned on until JDK 16; all JDKs before that had the exact same runtime access permissions as JDK 8), but rather the lack of strong encapsulation which led to many libraries simply being non-portable, which then made the applications using them non-portable without their knowledge. People only thought modules were the cause because modules landed in JDK 9 and were the most famous feature in that release (even though their runtime encapsulation wasn't turned on until JDK 16), and JDK 9 happened to be one of the biggest releases ever, which changed many internals that libraries had hacked into. If virtual threads had landed in JDK 9 rather than modules, the result would have been similar. The only reason you didn't see a lot of breakages due to virtual threads is that they were introduced after strong encapsulation. Second, the point about SecurityManager is a subtle one. SecurityManager was a complex security mechanism; this isn't. However, because integrity is a prerequisite to robust security, SM had to allow configuring integrity, but it was extremely hard to configure correctly. Now it's on by default. If you have any sort of authentication/authorisation mechanism in your application (nothing to do with SecurityManager), then an accidental mistake in any dependency or transitive dependency may result in a vulnerability that would allow a remote attacker to bypass your security mechanism, because the attack surface area is the entire program. Finally, the lack of integrity meant that some powerful performance optimisations can't be performed. Even simple constant-folding of Strings or final fields cannot be done because any library could unilaterally choose to mutate a String or a final.