On 23 March 2018 at 10:19, Martijn Verburg <martijnverb...@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
