书名：Mastering Java 11
作者名：Dr. Edward Lavieri
本章字数：239字
更新时间：2021-08-13 15:43:33

Encapsulating most internal APIs

JEP-260 was implemented to make the Java platform more secure. The core of this JEP's goal was to encapsulate the majority of internal APIs. Specifically, most of the JDK's internal APIs are no longer accessible by default. Currently, internal APIs deemed to be critical and widely-used remain accessible. In the future, we are likely to see functionality to replace them, and at that time, those internal APIs will not be accessible by default.

So, why is this change necessary? There are a few widely-used APIs that are unstable and, in some cases, not standardized. Unsupported APIs should not have access to internal details of the JDK. Therefore, JEP-260 resulted in increased security of the Java platform. Generally speaking, you should not use unsupported APIs in your development projects.

The aforementioned critical APIs (internal to the JDK) are as follows:

sun.misc
sun.misc.Unsafe
sun.reflect.Reflection
sun.reflect.ReflectionFactory.newConstrutorForSerialization

The aforementioned critical internal APIs are still accessible in the current Java platform. They will be accessible with the jdk.unsupported JDK module. Full JRE and JDK images will contain the jdk.unsupported module.

You can use the Java Dependency Analysis Tool, jdeps, to help determine if your Java program has any dependencies on JDK internal APIs.

This is an interesting change to watch. It is likely that the currently accessible internal APIs will not be accessible by default in future Java releases.