Concealed packages (was Re: Module API usage questions)

[Paul Benedict]

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.Bateman at 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
>