You're right in that JDK 9 highly values backward compatibility with JDK 8. However, there are still some caveats because of modularization of the JDK, that can

You're right in that JDK 9 highly values backward compatibility with JDK 8. However, there are still some caveats because of modularization of the JDK, that can affect your code (or your libraries) even when running on the classpath without modules: - some Java EE technologies that are tradionally part of Java SE as well, won't resolve by default when compiling/running on the classpath (JAXB will be the most noticeable) - JDK 9 strongly encapsulation internal implementation classes (think of types in com.sun.* and sun.* packages). When running on the classpath, there's a lenient form of strong encapsulation: you will get a warning on the console when reflectively using these types. In time, this lenient mode will be switched to a more strict enforcement. Ergo: time to wean code off the dependencies on internal implementation classes The first restriction you'll probably run into (if you for example have a Spring application). The second restriction is more an issue for library maintainers (though you should start complaining to said maintainers if your application starts printing warnings) All in all, it's not a 100% drop-in replacement, but it's close enough for most scenarios. The trick is to make sure your application will keep running in the future as well, when a more strict strong encapsulation regime will be enforced for classpath-applications as well. (full disclosure: I'm author of Java 9 Modularity, O'Reilly, which covers many migrations scenarios as well. See https://javamodularity.com https://javamodularity.com)