[jsr294-modularity-eg] Nested superpackages

[Andreas Sterbenz]

At JavaOne Glyn and I talked a bit about a few topics, including nested 
superpackages. I will try to summarize the conclusions. Glyn, please 
correct me if something does not match your recollection.

Summary: nested superpackages have value, but there is no agreement yet 
whether they have enough value to justify their inclusion. We need to 
better understand them (and explain them) before making a final decision 
about nested superpackages in JSR 294. One way to understand them better 
is to try them out in practice. As the extra complexity of implementing 
nested superpackages is low, the javac team has agreed to implement them 
as part of their JSR 294 work. The initial version of that implementation 
is expected to be available sometime this summer.

I suggest we go ahead with the plan of leaving them in for now and 
reexamining the solution in a few months. Please let me know if anyone 
disagrees.


And for completeness, a few words about the solution you proposed below. I 
agree that it is one possibility. However, I must point out that you are 
solving part of the problem at the language/VM level using superpackage 
and another part at the library level using very different mechanisms. It 
is not clear to me that this is simpler for developers to understand and 
maintain than having all access control take place at language/VM level 
using (nested) superpackages. Also, there may be developers that care 
about access control but do not want to use deployment modules.

Andreas.

Glyn Normington wrote:
> 
> *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