Unnamed module .. singular or plural?

[Alex Buckley]

On 7/13/2016 9:53 AM, Paul Benedict wrote:
> 2) Can you please confirm the following? If ClassLoader A has type
> com.domain.X in its unnamed module, and ClassLoader B has type com.domain.X
> in its unnamed module, and B is a child of A, it's possible developers may
> still end up getting the wrong X class instance. This example alludes to
> the common EE problem commonly manifested as a ClassCastException (e.g.,
> type X can't be cast to type X). So using unnamed modules in an EE server,
> this situation still remains, right?
>
> 3) Somehow all the unnamed modules must collapse (in notion) to represent a
> virtual class path. Even if they are not "the class path" as specified on
> the command line, all these unnamed modules function as such. Every type in
> every the unnamed modules has all their types exported .... so they are
> just amended to "the class path"? Am I correct?

I talk about unnamed modules in class loaders in the "Jigsaw Under The 
Hood" presentation.

I also talk about how the Java launcher construct known as the "class 
path" relates to the unnamed module of the application loader.

Despite a slide saying "Class loading doesn't change" in big letters, I 
evidently failed to communicate that the module system is opt-in. A 
container that spins class loaders on JDK 8 will work exactly the same 
way on JDK 9. The classes defined by those loaders will be in the 
loaders' unnamed modules, which are implicitly understood by the VM 
(i.e. public classes remain universally accessible) without any 
invocation of the module system API.

Only if the container invokes the module system API to associate the 
loaders with a module graph and a layer does the module system tell the 
VM "hey, look at these module boundaries, please enforce them".

Alex