----- Mail original ----- > De: "Stephen Colebourne" <scolebou...@joda.org> > À: "jigsaw-dev" <jigsaw-dev@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 <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 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
