Some points on JPMS/Jigsaw after he modularised some code (from Stephen Colebourne)

[Stephen Colebourne]

On 23 March 2018 at 10:19, Martijn Verburg <martijnverburg at gmail.com> wrote:
> Stephen's comments are in his blog post:
> http://blog.joda.org/2018/03/jpms-negative-benefits.html

Firstly, I want to emphasise that my goal is effectively that of a
retrospective, to examine what hasn't worked so well and to improve
things from where we are. The jigsaw team did a great job in getting
the feature out at all - I want to make sure it is used rather than
ignored or used as a blocker to progressing the JDK.


> @Stephen are you able to share the source code?

The source code is all public:
https://github.com/ThreeTen/threeten-extra
https://github.com/JodaOrg/joda-parent
https://github.com/JodaOrg/joda-convert
https://github.com/JodaOrg/joda-beans

While some of the problems are tool-based, the most fundamental issues
are about JPMS itself.

At the heart of the problem is the split between class-path and
module-path. Since this split has happened now, and can't "unhappen"
what is needed is a way to make it easier to manage (fix the problems
the split has created).

As it stands, a library developer cannot control whether they run on
the class-path or module-path. This increases the bug-surface of the
library, and requires testing in two different environments (which is
not widely known). Without being able to insist that a library is on
the module-path it is also clear that the benefits of strong
encapsulation and reliable configuration don't apply to library
consumers.

My belief is that a way needs to be found for a library author to
insist that their library is run as a named module. There are probably
a number of ways this could be achieved - I'm interested in whether
the change makes things better, not what the specific change is.

One approach is to say that modular jar files are always treated as
named modules:

- a modular jar on the class-path is treated as being named, not part
of the unnamed module It is therefore encapsulated, but depends on the
unnamed module (class-path), so does not have full reliable
configuration. There is the potential for some incompatibility with
this change where code that uses the modular jar now can't access the
encapsulated packages, but this is a Good thing (as the library author
specifically coded for that encapsulation). Any incompatibilities are
smaller than JPMS has already caused, and could be managed with the
existing command line flags. I would hope this does not require a JVM
spec change to achieve.

A second approach is to say that the module author must mark modules strict:

- a module author could mark a module as "strict" in module-info.java
so that it is not permitted to be on the class-path. This does not
force the whole application to move to the module-path - only strict
modules and their dependencies would need to move. At runtime, if a
strict module is found on the class-path an error occurs. I suspect
this requires a JVM spec change, so may be harder.

There may well be more approaches. My gut feeling is that the first
approach is the better one, being relatively simple and implementable,
but of course I may be wrong.

Ultimately, the requirement is that library authors who go to the
effort of adding module-info.java should see some benefits in doing
so, where today they only have increased cost through running as both
an unnamed and named module.

thanks
Stephen