6 Compatibility challenges when moving to Java 9 or later

 

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
  • Understanding the new JDK run-time image layout
  • Replacing the removed extension mechanism, endorsed standards override mechanism, and boot class path option

This chapter and chapter 7 discuss compatibility challenges when migrating an existing code base to Java 9 and beyond. You won’t be creating any modules yet; these chapters are about building and running an existing project on the newest release.

Why does moving to Java 9+ require two entire chapters? Can’t you install the newest JDK and expect everything to just work? Isn’t Java meant to be backward-compatible? Yes—if your project, including its dependencies, only relies on nondeprecated, standardized, 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.

As you’ll see in this chapter, the module system deprecated some Java features, removed others, and changed some internals:

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 run-time image directory layout

6.4 Selecting, replacing, and extending the platform

6.4.1 No more compact profiles

6.4.2 Extension mechanism removed

6.4.3 Endorsed standards override mechanism removed

6.4.4 Some boot class path options removed

6.4.5 No compilation for Java 5

6.4.6 JRE version selection removed

6.5 Little things that make big things fail

6.5.1 New version strings

6.5.2 Tool exodus

sitemap