Can automatic modules be made to work?

Stephen Colebourne scolebourne at
Fri Apr 28 10:44:43 UTC 2017

On 27 April 2017 at 19:50, Robert Scholte <rfscholte at> wrote:
> The returning question is: how can I as a *library builder* participate in
> adopting Jigsaw?

Indeed, the community really wants to help JPMS adoption and add
module metadata. Since bottom up won't work, a mechanism needs to be
provided that enables migration of any jar file, whether its
dependencies have been modularized or not.

> Which made me think of the concept of soft and strict modules. Assuming
> 'strict' is the preferred default, 'soft' or any equivalent alternative
> would be a new keyword which has the same effect as add-reads
> <module>=ALL-UNNAMED, but it's information is available at both compile time
> and runtime.
> With soft modules you can require a subset of modules.

I think that the notions expressed recently of "requires classpath",
"partial requirements", "incomplete/complete modules" [1] and
"strict/soft modules" (above) are all fundamentally the same idea.
Robert expresses a possible underlying mechanism well I think.

I'd envisage an additional keyword, or some other syntax, to mark a
module as not being able to specify all dependencies (because they are
not modules yet):

soft module org.joda.beans {
  requires org.joda.convert;
  // TODO requires guava, revisit when guava is released as a module

With this approach, I think JPMS adoption could be quite strong in the



More information about the jigsaw-dev mailing list