The implementation of the `checkPackageAccess` and `checkPackageDefinition` methods of `java.lang.SecurityManager` now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the `package.access` and `package.definition` security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module.

If your application is running with a `SecurityManager`, it will need to be granted an appropriate `accessClassInPackage.{package} RuntimePermission` to access any internal JDK APIs (in addition to specifying an appropriate `--add-exports` option). If the application has not been granted access, a `SecurityException` will be thrown.

Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions.

The `package.access` and `package.definition` properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls `Security.getProperty("package.access")`, it will not include the builtin non-exported JDK packages.

Also, when running under a `SecurityManager`, an attempt to access a type in a restricted package that does not contain any classes now throws a `ClassNotFoundException` instead of an `AccessControlException`. For example, loading `sun.Foo` now throws a `ClassNotFoundException` instead of an `AccessControlException` because there are no classes in the `sun` package.