Consider an automatic module MA which is required by an explicit named
module MN. MA could mention, in its exported API, public types from
other automatic modules (e.g. seems reasonable for jackson.databind to
have a method whose return type is from jackson.core) so we want MN to
read those other automatic modules.
The subtlety is that "other automatic modules" doesn't mean "every
legacy JAR on the modulepath". It means "every legacy JAR on the
modulepath which is required by an explicit named module, or is
otherwise given by -addmods".
Alex
On 4/25/2016 12:22 AM, Paul Bakker wrote:
I now understand (and tested) that when I use any automatic module
from a named module, the named module gets implicit readability to
*all* automatic modules. What is the reasoning behind this?
If a module A has a dependency on B and C, I get the impression
during migration that "requires B" would be sufficient for module A.
Up until the point that B is migrated to a named module, because than
suddenly A needs a "requires C" as well. Of course automatic modules
will never be an exact representation of a fully migrated situation,
but it would be nice to get as close as possible.
Paul
On 25 Apr 2016, at 08:59, Alan Bateman <alan.bate...@oracle.com>
wrote:
On 25/04/2016 07:35, Paul Bakker wrote:
That doesn't seem to be the case, I can run successfully, as long
as I have the right -addmods. I've pushed my example here if you
want to take a further look at it:
https://github.com/paulbakker/automaticmodules-example
<https://github.com/paulbakker/automaticmodules-example>
I wasn't clear. My comment was on when the scenario is changed
slightly to have an additional explicit module in the picture, say
java.desktop. In that case then javac is granting implicit
readability and so requiring jackson.databind allows the module to
make use of types in java.desktop. It may be specific to system
modules but I will create a bug on that.
-Alan.
