Problem solved by the feature

JEP 411 marked the SecurityManager and related classes such as java.security.AccessController as 'deprecated for removal' since JDK 17.

Currently the Gson code uses AccessController:

This could become a problem when a future JDK version actually removes the SecurityManager and related classes, and Gson users cannot upgrade then.

Side note: Gson's unit test ReflectionAccessTest.testRestrictiveSecurityManager() also uses the deprecated SecurityManager class, but maybe we should keep this for now to make sure Gson's behavior for JDK versions with SecurityManager is correct.
Once we want to build with JDK versions without SecurityManager we can investigate solutions for this, e.g. moving the test into a separate test class which is excluded when building with newer JDK versions.

Feature description

We should already consider solutions for the case that AccessController does not exist, to avoid any issues if users want to upgrade to future JDK versions.

One solution might be to wrap the usage of AccessController inside a try-catch which catches NoClassDefFoundError and in that case falls back to executing the code to access the fields outside the scope of AccessController#doPrivileged. (To be verified that this actually works as desired.)

Another alternative might be to refactor the code to first check with Class#forName or similar if AccessController exists (and remember the result).

It might also be good to add a unit test which verifies that the AccessController#doPrivileged usage actually has the desired effect. It seems that is currently not covered by any test (?).
Then we could be more confident that whatever change we make does not break the code for users who have a restrictive SecurityManager on an older JDK.