On 24 April 2017 at 19:54, <mark.reinh...@oracle.com> wrote: > An explicit module that depends upon one or more modules that are > automatic today is, itself, no more stable than those automatic modules. > It could be broken when those automatic modules are modularized > explicitly, and if it `requires transitive` an automatic module then any > modules that depend upon it could be broken when that automatic module > is modularized explicitly.
I find this to be a completely artificial pure view of the world. Most projects do not have internal packages, and if they do, most end-users do not use them. When developers upgrade an artifact in Maven, they expect to have incompatibilities, so a smaller set of packages is just fine. Its a normal part of software development today, not an aberration. Frankly though, if you think automatic modules are as bad as you make out, you should simply remove them. On another thread you wrote: On 24 April 2017 at 16:46, <mark.reinh...@oracle.com> wrote: > Automatic modules are best viewed as a transitional tool that allows you > to modularize an isolated, unpublished set of components in a top-down > fashion over time. You can use existing published JAR files, from Maven > Central or elsewhere, as automatic modules. The names and APIs of those > automatic modules are unstable and will change as they are modularized > explicitly, but in an isolated set of components you can easily adjust > your own `module-info.java` files as needed to cope with those changes. And for what benefit? Why would a company put itself through the pain of relying on potentially thousands of external dependencies via automatic modules, taking a hit every time one gets converted to a real module. Where is the payback for that company? What is the benefit they gain? If this is the only use case for automatic modules, then they should be dropped. Unfortunately, the concept of bottom-up full modularization simply won't work, no matter how much the Jigsaw team hopes it will. The process would take forever, may not be possible for some projects, will be side-tracked into the release cycles of larger projects, be blocked by dead projects and for many other reasons just stall. I'd also note that everyone outside Oracle has given the same message. For example, there are 42 separate projects at Apache Commons, some of which have multiple release streams - thats an awful lot of work you're expecting unpaid volunteers to do, particularly when each has to be released in order. (A typical release at Apache Commons is a multi-week affair, so even if Apache Commons had the energy to release everything, it would take all their energy for well over a year.) There are even 11 different Joda projects to work on, with active ones depending on less active ones, I would be forced to do artificial releases just to satisfy a bottom-up migration. The only approach that makes any sense to migration is to drop the artificial purity goal. We already have build tools (Maven, Gradle) that manage versions, locking them in to form a working graph of artifacts. When a version is changed, sometimes things break, and we fix them. This is all normal software development. It is not something for JPMS to try and fight or fix. As discussed before, removing automatic modules and allowing modules to have partially specified dependencies [1] 1b allows projects to migrate to modules immediately. This would be a huge win. Any project that is interested could write module-info immediately, even if all it was doing was specify the exported packages. They would release within their normal release cycles, and depend on whatever other modules are already released at the time of release. As more and more modules become available, the partial requirements will turn to complete requirements, and thus explicit modules. Plus, it is really easy for the build tool to work with. If the jar has a module-info it goes on the modulepath, otherwise it goes on the classpath. And AFAICT it would just work. Worrying about getting incomplete "impure" modules in Maven Central is simply the wrong concern. If we keep the current design, and insist on no automatic module dependencies in Maven Central, then JPMS will simply not be adopted outside a few private niches. Stephen [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011686.html
