Implied readability + layers

Alex Buckley alex.buckley at
Thu Nov 5 18:44:36 UTC 2015

On 11/5/2015 1:30 AM, Ali Ebrahimi wrote:
> Hi alan,
> So far quite disappointing!
> But I think Alex's last response on this topic says opposite of this:
> "We'll have to think about the implication of com.baz in layer1 sometimes
> offering a 'requires public' on in layer1, and sometimes offering a
> 'requires public' on in layer2, depending on who is reading com.baz
> in layer1."

Alan and I have discussed this. It's not possible for com.baz in layer1 
to "switch" which it depends on. There are two reasons.

First, in some loader of layer1, code in com.baz refers to a type 
exported by at 1, and thus triggers class loading of that type from 
whichever class loader in layer1 is responsible for loading at 1. 
The loader for com.baz will be marked by the JVM as an "initiating 
loader" for the type -- see JVMS8 5.3.2 -- so any further execution of 
code in com.baz that refers to the type will get the same class as 
initially loaded (from at 1). There is no way around this.

Second, when code in calls code in com.baz, the callee has no 
idea who the caller is. The bytecodes for method invocation don't pass 
that information. Since code in com.baz doesn't know the caller is in layer2, there is no possibility of com.baz "switching" to 
invoke code in at 2 in layer2 rather than at 1 in layer1.

It would be possible to write code in com.baz that reflectively detects 
its caller, then reflectively invokes code in either at 2 or at 1, never referring to exported types of any module via 
the constant pool. If you do this, good luck with all the mental 
accounting -- it's not a sane technique to build into the module system. 
Since layers can come and go, it makes sense for the module system to 
isolate code in a parent layer (com.baz in layer1) from the comings and 
goings of code in a child layer ( in layer2).

> In this case adding  'requires public' on in layer2 does not mean
> we should pick at 2 for com,foo?
> This scenario would have many usages in future when world would filled with
> modules and developers would have to use newer versions of modules to fix
> bugs.
> What if compiled against at 2? adding redundant requires
> in does not help and my app will fail.
> So what is advantage of multiple layers?

Inconsistent separate compilation has caused problems at run time since 
1995. I was very clear in "Project Jigsaw: Under The Hood" that mixing 
multiple versions of a module must not be done casually.

What layers give to a managed runtime (e.g. an app server) is i) freedom 
to map modules to loaders (not only 1:1 but also n:1 and n:m), and ii) 
freedom to isolate different versions of modules from each other (see 
slide 55 in


More information about the jigsaw-dev mailing list