Mark, thanks for your reply. Some things for you to respond to when you can, please:
1) I think 5.4 clearly contradicts 3.1 on the surface. I don't think it serves readers any good (it didn't me) to first assert there is just "one unnamed module" and then, if you keep on reading to the advanced topics, find out there's many unnamed modules. If you don't mind an editorial suggestion, it's better to state the fact up-front, and then note to the reader that 3.1 just deals with the case of one. Thanks. 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? Cheers, Paul On Wed, Jul 13, 2016 at 10:06 AM, <mark.reinh...@oracle.com> wrote: > 2016/7/13 7:35:08 -0700, pbened...@apache.org: > > Given that ClassLoader#getUnnamedModule is not a static method, the > > signature implies different class loaders can have different unnamed > > modules. I only say "imply" because I would expected a static method to > be > > the source of a singleton object. AFAICT, there is just one "unnamed" > > module according to the SOTMS... so what's with requiring non-static > > access? > > http://openjdk.java.net/projects/jigsaw/spec/sotms/#unnamed-modules > > - Mark >
