6 Compatibility challenges when moving to Java 9

 

This chapter covers:

  • why JEE modules are deprecated and not resolved by default
  • compiling and running code that depends on JEE modules
  • why casts to URLClassLoader fail
  • the new JDK runtime image layout
  • replacing the removed extension mechanism, endorsed standards override mechanism, and boot class path option
  • handling all the smaller changes, like the new format of the Java version string

In this chapter and in chapter 7, I discuss the compatibility challenges when migrating an existing code base to Java 9 and beyond. We won’t be creating any modules yet, it’s just about building and running your existing project on the newest release.

Why would moving to Java 9 require two entire chapters, though; can’t you simply install the newest JDK and expect everything to just work? Isn’t Java meant to be backwards compatible? Yes, and it is if your project, including its dependencies, only relies on non-deprecated, standardized, and documented behavior. But that’s a big if and it turns out that in the absence of any enforcement the wider Java community has strayed from that path.

6.1  Working with JEE modules

6.1.1  Why are the JEE modules special?

6.1.2  Manually resolving JEE modules

6.1.3  Dropping in third-party implementations of JEE modules

6.2  Casting to URLClassLoader

6.2.1  Application class loaders, then and now

6.2.2  Getting by without URLClassLoader

6.2.3  Finding troublesome casts

6.3  Updated runtime image directory layout

6.4  Selecting, replacing, and extending the platform

6.4.1  No more compact profiles

6.4.2  Extension mechanism was removed

6.4.5  No compilation for Java 5

sitemap