Yes, that's my concern, but it's really only secondary to something else. I am more concerned that specifying both seems redundant. The JVM should be able to infer at resolution time that what's not exported is concealed. There may be a grander design at play which I yet to understand, but I don't see how specifying what's concealed adds more information to the mix than you already have.
If type "p1.A" in module "m1" gets loaded, and "p1.A" requires "p2.B" but "p2" doesn't exist, the class is unavailable. Causes for package "p2" not existing: 1) It exists in another module but was never exported 2) It doesn't exist in any module including the current module If "p2" does exist in the current module, then three things could happen: 1) If "p2" is exported from my module, it's safe to use because the JVM knows all exported packages. 2) If "p2" is concealed in my module and no "p2" is exported in any other module, it's safe to use 3) If "p2" is concealed in my module but "p2" is exported by another module, then (fill in the blank) I leave "(fill in the blank)" to be filled in. This is where I am fuzzy on what is currently specified. However, I am trying to illustrate that the JVM should be able to infer what's concealed since it's the same, in my opinion, as not exporting. Cheers, Paul On Wed, Jul 20, 2016 at 1:47 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > On 20/07/2016 19:34, Paul Benedict wrote: > > Alan, is the JVM going to verify that what's listed in ConcealedPackages > structure actually exists as packages in the module? > > If you asking if it scans the contents of the JAR file to check if the > ConcealedPackages attribute is correct then "no". Are you concerned with > tampering or being out of sync with the contents of the module (updated by > buggy tool for example)? > > -Alan >
