Implied readability + layers

Alan Bateman Alan.Bateman at oracle.com
Fri Nov 6 16:48:12 UTC 2015



On 06/11/2015 10:59, Ali Ebrahimi wrote:
> :
>
> module com.foo {
>          requires com.baz;
>
>          exports com.foo;
>
> }
In this example then com.foo will also need to require com.bar as 
otherwise com.foo will not compile (I assume you've deliberately removed 
the requires public for this example).

In any case, I think what you have here is:

layer1:
     com.bar at 1
     com.baz reads com.bar at 1

The (library) module com.baz has com.bar types in its API.

layer2
     com.bar at 2
     com.foo reads com.baz
     com.foo reads com.bar at 2


> :
>
>
> Result:
>
> bar1
> bar2
>
> As you can see com.foo reads com.bar at 2 without reflection.
Yes, because when creating the configuration for this layer then you are 
resolving com.bar and have arranged that it be found with the 
before-finder. You would get the same thing if you just resolved com.foo 
because resolving com.foo's dependences would require finding com.bar.

In any case, I think you will start to see some of the issues that Alex 
warns about when you change com.foo.Main to do more than invoke 
toString.  If you change it to create Bar and Baz objects for example 
then it's easy to provoke this example to fail with a loader constraint 
violation.

-Alan


More information about the jigsaw-dev mailing list