[jsr294-modularity-eg] Nested superpackages

[Glyn Normington]

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 
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

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 
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?

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 [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?

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).

Glyn

> 
> 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
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU





-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070508/6a6c548c/attachment-0001.html