[jsr294-modularity-eg] Nested superpackages
Andreas.Sterbenz at Sun.COM
Tue May 8 04:42:47 EDT 2007
Glyn Normington wrote:
> Actually, the 'if' in "So if we really want JSR 294 to address the
> requirement exemplified by LUNI, [...]" was deliberate. You see I'm not
> at all convinced that this is a requirement worth the additional
> complexity of solving in JSR 294, given that JSR 291 fragments provide
> an existence proof of other ways to address this requirement.
You will have to elaborate on how JSR 291 solves the issue. Recall that in
the example  the requirements come down to:
(a) Lang/IO/Util are part of one "component"
(b) java.lang can access internal.lang
(c) java.lang can access internal.misc
(d) java.util can access internal.misc
(e) java.util CANNOT access internal.lang
(f) code outside the component CANNOT access internal.misc
If there is no Java language support for nested superpackages, how are
access control violations caught by a JLS compliant compiler?
If all classes in Lang/IO/Util are loaded by one classloader and there is
no nested superpackage access control at runtime, how are access control
violations caught at runtime by a JVMS compliant VM and Java SE compliant
And finally, how does this stack up against the goals outlined in the
strawman . In particular, goal 4 and the statement
"JSR 294 is intended to be independent of the deployment mechanism and can
be used with JAR files and existing ClassLoaders, JSR 277 modules, or
other deployment methods."
that you explicitly embraced in your mail to the EG on 3/27?
More information about the jsr294-modularity-eg