Untrusted devices behind one router, trusted devices behind another router, both routers behind a third. The routers should be dumb, rock hard, and nat. If the untrusted devices were behind just the outer router they could potentially intercept trusted traffic traversing that network. If the trusted devices were behind just the outer router, I guess the untrusted devices might somehow use IP tricks to enumerate devices or something.
They mention vlans, and say it's basically a homemade vlan. Why not use vlans then? No mention of DMZs. Or if you have a single router with configurable firewall, couldn't you just firewall traffic between untrusted and trusted ports? I'm not sure of the context of this idea. Do they make cheap routers with enterprise-level hardening that don't support firwalls?
I'm guessing you only read the issue or title on that link, because the second comment on that issue is from one of the Gradle maintainers suggesting using toolchains (which I linked to), with follow ups from various users advising some success, allowing them to target Java 16 while running Gradle on an earlier, supported version.
The last comment by a gradle team member, before closing the ticket says "... you won't be able to run Gradle 6.8.x on Java 16". Some users having some success compiling isn't really a ringing endorsement of a build system when it's clearly not working completely.
The takeaway is "make sure you use a tool like R8 or ProGuard to remove unused code paths". That's where most of the savings came from, and the advice applies to Java projects as well.
But true, if you care about every last byte, you might use Java instead. You might also use another language entirely.
Knowing this wasn't a Google thing, I was a bit thrown by the update being announced by Google. Definitely recommend headlining the original developers' announcement instead.
