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
