Re: automatic modules leaking types when using addmods

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

Re: automatic modules leaking types when using addmods

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 oth

Re: automatic modules leaking types when using addmods

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" w

Re: automatic modules leaking types when using addmods

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 I wasn't clear. My comment was

Re: automatic modules leaking types when using addmods

I understand this statement from the perspective of automatic modules. Not so much from the perspective of named modules however. Why would it be necessary to give implicit readability to all automatic modules when you're just explicitly using a single one? Paul > On 25 Apr 2016, at 02:38, Pau

Re: automatic modules leaking types when using addmods

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 Paul > On 25 Ap

Re: automatic modules leaking types when using addmods

On 24/04/2016 21:00, Paul Bakker wrote: So when modules B, C and D are automatic modules and named module A depends on B, A also gets implicit readability to C and D? What is the reasoning behind this automatic implicit readability? It makes migration less reliable I think, because it hides wh

Re: automatic modules leaking types when using addmods

Automatic modules live in a classpath-like world. Everything is exported to each other. You use this feature if you don't have time to migrate to a modular architecture. On Apr 24, 2016 3:01 PM, "Paul Bakker" wrote: > So when modules B, C and D are automatic modules and named module A > depends o

Re: automatic modules leaking types when using addmods

So when modules B, C and D are automatic modules and named module A depends on B, A also gets implicit readability to C and D? What is the reasoning behind this automatic implicit readability? It makes migration less reliable I think, because it hides what dependencies a module really has. Paul

Re: automatic modules leaking types when using addmods

On 24/04/2016 10:57, Paul Bakker wrote: Hello, Another question related to automatic modules. I have the following code: import com.fasterxml.jackson.core.JsonFactory; ... JsonFactory f = new JsonFactory(); System.out.println(f.getCodec()); This code clearly d

automatic modules leaking types when using addmods

Hello, Another question related to automatic modules. I have the following code: import com.fasterxml.jackson.core.JsonFactory; ... JsonFactory f = new JsonFactory(); System.out.println(f.getCodec()); This code clearly depends on jackson.core. So my module-info co