automatic modules leaking types when using addmods

[Peter Levart]

On 04/25/2016 09:09 PM, Alex Buckley wrote:
> 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

In other words, automatic module implicitly reads all modules much like 
it would have "requires public" specified for all of them in its 
hypothetical module-info (or just for automatic modules?)...

Regards, Peter

>
> 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.Bateman at 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.
>>