W.r.t. class loader related change in JDK 9, you are probably safe if you don’t depend on the internal implementation. JEP 220 [1] documents the compatibility risks due to the Modular Runtime Image change. A few things worth mentioning:
- the built-in classloader may not be URLClassLoader as this bug reports.
- Custom class loader with null parent
It is the implementation detail if system classes are loaded by null or non-null class loader.
More system classes will be deprivileged. i.e. the defining class loader of system classes may be changed from the boot class loader to the extension class loader. Any custom ClassLoader delegates to null as the parent class loader may run into ClassNotFoundException. [2][3] is one example.
[3] tools.jar no longer exists in JDK 9. All JDK classes are linked into the modular runtime image and visible to the system class loader. it’s not uncommon for existing code to create a URLClassLoader to find classes from tools.jar. It will run into CNFE if such URLClassLoader delegates to null. That will be impacted.
[1] http://openjdk.java.net/jeps/220
[2] https://bugs.openjdk.java.net/browse/JDK-8042244
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=466683