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