"exports" directive does not open module's resources for dependent modules

[Alexander Udalov]

Thank you, I've re-read JLS 7.7.2 and understand now that it behaves
as expected. I'll continue exporting and opening every package then.

Alexander

On Fri, Sep 15, 2017 at 3:52 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 15/09/2017 13:14, Alexander Udalov wrote:
>>
>> It looks like exporting a package from a (non-open) module with an
>> "exports" directive is not enough to ensure that
>> Module.getResourceAsStream on that module would load resources from
>> the module. Surprisingly, adding an "opens" directive for the same
>> package to the module declaration allows resources to be found.
>>
>> I've put up a simple project to demonstrate this issue:
>> https://github.com/udalov/jigsaw-resources-are-not-exported
>>
>> I'm wondering whether this is a bug or expected behavior?
>
> Yes, this is expected behavior. The javadoc has all details. In your
> example, if kotlin.reflect is using Class.getResourceXXX or
> Module.getResourceAsStream to locate a non .class resource in module X then
> module X needs to open the package with the resource to at least
> kotlin.reflect.
>
>
>> I would
>> expect that exporting a package would also open it not only for uses
>> of reflection, but for resource loading. I can't find anything related
>> to resources in the JLS, but p.7.7 "Module Declarations" gives a clear
>> impression that the "exports" directive gives a superset of
>> functionality of the "opens" directive in this regard.
>
> I think you need to re-read JLS 7.7.2. As `opens` doesn't grant any access
> at compile-time then you think of it as being a subset of `exports` in this
> phase.  On the other hand, `opens` grants access to the public
> classes/members and additionally reflective access to all members of all
> classes at run-time so you can think of it as a superset in this phase. The
> resource APIs just build on this.
>
> -Alan