Just to add a note that came up in a twitter conversation. Modules are not artifacts. [1] ergo, module names are usually not artifact names yet, automatic module names are derived from artifact names
Its no wonder that I have seen lots of confusion between modules and artifacts, Jigsaw itself is mixing the two concepts! Stephen [1] http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html On 25 April 2017 at 13:08, Stephen Colebourne <scolebou...@joda.org> wrote: > 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
