Alan, is the JVM going to verify that what's listed in ConcealedPackages structure actually exists as packages in the module?
Cheers, Paul On Tue, Jul 19, 2016 at 4:56 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > On 19/07/2016 21:16, Paul Benedict wrote: > > > Can you into more about packages "not be package of your module"? I > apologize for not understanding. If I assemble myself a jar file and my jar > file has 10 packages and I have an "empty" module-info.java file (i.e., > just a name and curly braces), don't I automatically have 10 concealed > packages? So that's what I don't understand -- why I need to tell anyone > what I have hiding. > > And what if I don't list out my concealed packages? What happens to my 10 > packages at runtime? > > If you use the jar tool to create the modular JAR then it will scan the > contents (at packaging time) and add the ConcealedPackages attribute with > names of the 10 packages. > > If you use some other tool to create the JAR file then it will work too, > it just means that the JAR file contents will be scanned when the JAR file > is opened in order to get the list of packages. > > On the other hand, if you are rolling ModuleDescriptors yourself and are > ignoring concealed packages then there will be problems. For starters, it's > not clear if the classes in these packages will be loaded, it all depends > on how your class loader works. Assuming the classes can be loaded then > they won't be in module M, they will instead be in the unnamed module of > their defining loader. Accessibility will likely be an issue. Module M may > not read the unnamed module and so types in the unnamed module won't be > accessible. Other scenarios are possible too, I can think of cases where a > type is loaded (in the unnamed module) but it can't link to its super type > in M. In summary, lots of potential issues if you drop the concealed > packages. > > -Alan >
