SQL Developer JDK 8 support dropped: bundled-JDK build or shared system JDK for team installs?

Our team is planning a standardized SQL Developer rollout, and the documented JDK compatibility boundary in recent releases has forced a decision we haven't resolved. Newer SQL Developer versions no longer run on JDK 8 and require a newer JDK (11 or 17 depending on the release), and the Windows download comes in two variants: one with an embedded JDK and one "no-JDK" build that uses a system-installed Java.

The bundled build simplifies support—everyone runs the same pinned Java version—but it enlarges each install and means the JDK version is fixed per SQL Developer release. The no-JDK variant lets us manage one shared system JDK across tools, but introduces a dependency we must keep aligned with whatever each SQL Developer version's release notes list as supported.

We connect to a mix of database editions, and since the client itself is no-cost, the only real cost concern is on the database/pack licensing side, which we're handling separately.

For teams that have standardized installs: which variant did you choose and why? How do you handle JDK version drift when upgrading SQL Developer on the no-JDK build? Is there a documented way to point the no-JDK build at a specific JDK path per machine?