[jsr294-modularity-eg] Nested superpackages

[Andreas Sterbenz]

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 [1] 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 
libraries?

And finally, how does this stack up against the goals outlined in the 
strawman [2]. 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?

Andreas.

  [1] 
http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2007-May/000060.html
  [2] http://blogs.sun.com/andreas/resource/superpackage_strawman.html