13 Module versions: What’s possible and what’s not

 

This chapter covers

  • Why the module system doesn’t act on version information
  • Recording version information
  • Analyzing version information at run time
  • Loading multiple module versions

As briefly mentioned in section 1.5.6, the JPMS doesn’t support module versions. But then what is jar --module-version good for? And didn’t section 12.3.3 show that ModuleDescriptor can at least report a module’s version? This chapter clears things up and looks at module versions from a few different angles.

We’ll first discuss in what ways the module system could support versions and why it doesn’t do that (section 13.1). It at least allows you to record and evaluate version information, though, and we’ll explore that next (section 13.2). Last on the list is the Holy Grail: running different versions of the same module (section 13.3). Although there’s no native support for that, there are ways to make it happen with some effort.

By the end of this chapter, you’ll have a clear understanding of the module system’s limited support for versions. This will help you analyze your application and can even be used to proactively report possible problems. Maybe more important, you’ll also know the reasons for the limitations and whether you can expect them to change. You’ll also learn how to run multiple versions of the same module—but as you’ll see, it will rarely be worth the effort.

13.1 The lack of version support in the JPMS

13.1.1 No support for multiple versions

13.1.2 No support for version selection

13.1.3 What the future may bring

13.2 Recording version information

13.2.1 Recording versions while building modules

13.2.2 Accessing module versions

13.3 Running multiple versions of a module in separate layers

13.3.1 Why you need a starter to spin up additional layers

13.3.2 Spinning up layers for your application, Apache Twill, and Cassandra Java Driver

Summary