Avoid Internal JDK sun.* and com.sun.* Packages
ID |
java.avoid_sun_packages |
Severity |
high |
Remediation Complexity |
trivial |
Remediation Risk |
low |
Remediation Effort |
low |
Resource |
Reliability |
Language |
Java |
Tags |
imports, reliability |
Rationale
The sun. and com.sun. packages are internal implementation details of the JDK. They are not part of the official Java SE API and may change or be removed between JDK releases without notice. Starting with JDK 9 and the Java Platform Module System (Jigsaw), access to these internal APIs is actively restricted, causing IllegalAccessError at runtime unless explicit --add-opens or --add-exports flags are passed to the JVM.
// Bad -- relies on internal JDK implementation
import sun.misc.Unsafe;
import com.sun.net.httpserver.HttpServer;
The com.sun. namespace is not reserved for the JDK. Third-party products publish libraries there — the LibreOffice/OpenOffice UNO API (com.sun.star.), Java Native Access (com.sun.jna.), JavaMail, the JAXB reference implementation, Jersey 1.x — and those carry none of the risk above: the vendor’s jar is the public API, so there is nothing to migrate to. Imports under the prefixes listed in allowedPrefixes are therefore not reported.
// OK -- third-party library that happens to live under com.sun.
import com.sun.star.beans.XPropertySet;
import com.sun.jna.platform.win32.Shell32Util;
Note: this rule flags import declarations only. Fully-qualified inline references (e.g. sun.misc.Unsafe.getUnsafe()) are not covered.
Remediation
Replace internal API usage with official Java SE equivalents or well-maintained third-party libraries:
// Good -- use the public API
import java.lang.invoke.VarHandle; // instead of sun.misc.Unsafe
import java.net.http.HttpClient; // instead of sun.net.www.protocol.http
When no public replacement exists, isolate the internal usage behind an abstraction layer so it can be swapped out when upgrading the JDK.
Configuration
| Property | Default | Meaning |
|---|---|---|
|
|
Package prefixes under |