JPMS Maturity Model

maturity-model.md

Maturity Model

Libraries, frameworks, and tools (IDEs, build tools) have widely varying support for the JPMS. I would like to create a model that makes it easy to judge a project for what it can and can't (yet) do - both for users and maintainers.

Conditions can usually be split into those for libraries/frameworks and those for tools, but that's not clear cut. Bytecode analysis tools, for example, may fall into both categories. So always look at both categories, and check which conditions apply to a given project.

This is work in progress - feedback welcome!

Level 0 - Denial: Don't break!

Libraries, frameworks

• don't break on Java 9+ class path

Tools

• don't break when declaration or descriptor is present
• using only class path is ok

Level 1 - Guilt: Absolute minimum support

Libraries, frameworks

• work on module path
• define module name in manifest

Tools

• syntax support for declaration
• compile/run/test/package modules (i.e. use module path) when declaration/descriptor is present
• place all dependencies on the module path
• tests are patched into main modules

Level 2 - Bargaining: Refined and configurable support

Libraries

• ship modular JAR
• keep working on class path
• use lookup-based metaprogramming instead of reflection

Tools

Make dependency resolution strategies configurable and add more advanced ones:

• all class path (as per level 0)
• all module path (as per level 1)
• only root and direct dependencies on module path, rest on class path
• pull in service providers

For test frameworks, make test execution configurable and add more advanced options:

• run tests on class path (as per level 0)
• patch tests code into main module (i.e. main and test code run in the main module; as per level 1)
• allow module declaration in test sources that is merged with main declaration and patch main code into test module (i.e. main and test code run in the test module)
• allow module declaration in test sources that depends on main module (i.e. main and test code in separate modules)

Some examples

• Maven compiler 3.8: 2 except configuration
• Surefire 3.0.0-M2: 2
• IntelliJ 2017.2
  • project builder: 1
  • test runner: 0
• Eclipse Oxygen.1a: 1

@gunnar: I think that would blow up the post and make it too unwieldy. I'll link to other sources describing that, though.

This got a bit lost in twitter correspondence. But there is something missing about support for ModularLayers.
I believe a mature library should support modules that are loaded via ModulLayers.

This is non-trivial to get right, if you rely on cached lookup objects from each module. As you cannot keep strong references to them.