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

[Remi Forax]

----- Mail original -----
> De: "Stephen Colebourne" <scolebourne at joda.org>
> À: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoyé: Vendredi 23 Mars 2018 13:51:06
> Objet: Re: Some points on JPMS/Jigsaw after he modularised some code (from 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

You can check dynamically if a class is in the unamed module (classpath) or not and emit an error message.

This is exactly what the VM does when the class version is wrong.

Rémi