On 20/07/2016 20:13, Paul Benedict wrote:
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.
I don't think I understand what you mean. If you mean that the
ConcealedPackages attribute is redundant then you are right. As I said,
it's just an optimization to avoid scanning the JAR file to determine
the complete set of packages in the module. However, you don't see it
because it is added or updated by the `jar` tool when you create or
update a modular JAR. If you use other tools then the attribute won't be
present and the implementation will fallback to scanning the JAR file to
get the set of packages in the module. The set of packages minus the set
of exported packages is the set of concealed packages.
If type "p1.A" in module "m1" gets loaded, and "p1.A" requires "p2.B"
but "p2" doesn't exist, the class is unavailable.
I think you mean that p1.A has a reference to p2.B. If package p2 is not
local and is not in any module that m1 reads then there must be a
mismatch between the compilation and run time environments. You will
probably get a NoClassDefFoundError here.
:
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
It doesn't matter if p2 is exported or not. Assuming that p2.B is a
public type then it is accessible to all code in m1.
3) If "p2" is concealed in my module but "p2" is exported by another
module, then (fill in the blank)
If "exported by another module" means exported to m1 then it's not a
valid configuration. This will be cause by the post-resolution checks,
essentially resolveRequires that you were looking at earlier in this thread.
-Alan
