You can't blame Mark Reinhold, chief architect of the Java Platform Group at Oracle, for showing a bit of frustration with Java developers who insist on calling methods that have been deprecated for years, or for referencing internal Java APIs when they know darn well that they shouldn't be.
"The JDK [Java Development Kit] has many internal APIs that were never meant to be used by external tools," Reinhold said in his opening keynote at the first Oracle Code One conference. "For decades, we've been warning developers against using them. They've done so anyways."
Hands off those Java internal APIs
Developers have used Java internal APIs mostly because of their availability. The manner in which the JDK has historically been developed meant that developers could still access various APIs not intended for external use through a simple import. There was no easy way to isolate these APIs from developers without also cutting off access to the maintainers of the JDK. Public accessibility became a necessary evil. However, with the new Java modularity system, restricted access to classes such as GC, Unsafe and BASE64Encoder is easily achieved. And not only is restricting access to Java internals now possible, but there are compelling reasons to do it. The security of the platform is a primary reason. "Of the six high-impact zero-day vulnerabilities reported since JDK 7 in 2011, three of them would have been prevented if we were able to encapsulate Java's internal APIs," Reinhold said.
The -jdkinternals flag on the Jdeps tool will identify Java internal API dependencies.
Starting with JDK 9, if your code uses Java internal APIs, it will not compile.
Mark ReinholdChief architect, Java Platform Group, Oracle
But security implications are not the only reasons for limiting access to internal Java APIs. Not being allowed to change or deprecate these classes for fear of breaking running applications makes the JDK harder to maintain, while it also slows down its evolution. So it should come as no surprise to find out that Oracle is now serious about putting an end to the practice of treating classes in the sun.misc package as though they were part of the standard.
"Starting with JDK 9, if your code uses Java internal APIs, it will not compile, and it may generate warnings at runtime," Reinhold said. "In a future release, it will not run."
Total eclipse of the sun.misc
Of course, Oracle will not leave software developers in the lurch. Since Java 8, the JDK has included a dependency validation tool named Jdeps. It not only identifies any Java internal API dependency but also suggests alternative classes that you can use instead. There's even a Maven Jdeps plugin, so Java dependency analysis reports can be generated every time a CI build runs, warning the team if a dangerous Java internal API has been referenced.
This means it's time for developers to stop referencing internal Java APIs. And if developers can't enforce this best practice for application development on their own, eventually, the JDK will enforce it for them.
Dig Deeper on Core Java APIs and programming techniques
