[jsr294-modularity-eg] Nested superpackages
glyn_normington at uk.ibm.com
Tue May 8 09:07:47 EDT 2007
Andreas Sterbenz <Andreas.Sterbenz at sun.com> wrote on 08/05/2007 09:42:47:
> 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
> > 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
> 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
There are two solutions that come to mind. Neither of them is perfect and
I'll describe the imperfections, but note that the currently proposed
strawman isn't perfect either as (i) nested superpackages add conceptual
burden, and (ii) the information hiding is imperfect in allowing
unexported class names to 'clash'.
The first solution is to make lang, util, net, and io into a host and
three fragments of the host respectively. Only the java. APIs are
exported. This satisfies all the above requirements except for e.
The second solution is to make lang, util, net, and io into separate
bundles and to export the java. APIs and internal.misc. The latter export
is tagged with an attribute 'impl:=true;mandatory="impl"' which forces
importers to specify 'impl:=true'. This satisfies all the above
requirements provided there is some additional means to ensure that only
those bundles which should be allowed to access internal.misc are allowed
to specify 'impl:=true' on their imports of internal.misc. This comes down
to appropriate control of the source code - something which is also needed
if JSR 294 is used to solve these requirements (otherwise a developer
could, for example, export internal.misc as necessary and break f).
> If there is no Java language support for nested superpackages, how are
> access control violations caught by a JLS compliant compiler?
Only the access control requirements that can be expressed using top-level
superpackages can be caught. Nested superpackages could bring this
additional level of checking which is clearlg a benefit, although we
should consider whether they are worth the cost.
> If all classes in Lang/IO/Util are loaded by one classloader and there
> no nested superpackage access control at runtime, how are access control
> violations caught at runtime by a JVMS compliant VM and Java SE
Some access violations, such as f, would manifest themselves as class
loading failures. Others could be caught by appropriate use of top-level
superpackages. Some, such as e, would not be possible to catch without
adopting the second solution described above.
> 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
> 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?
The current strawman satisfies goal 4 and the above quoted statement.
Therefore any (usable) subset of the strawman also satisfies goal 4 and
the above quoted statement. In particular, the strawman minus nested
superpackages satisfies these goals.
The question is whether the strawman minus nested superpackages provides
an adequate basis for deployment modules, which I think it does, and
whether it is usable, which I think it is (because it doesn't have the
extra conceptual burden or the semantic rough edge of clashing unexported
classs names exhibited by the current strawman).
>  http://blogs.sun.com/andreas/resource/superpackage_strawman.html
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the jsr294-modularity-eg