Proposal: #ResourceEncapsulation and #ClassFilesAsResources

[mark.reinhold at oracle.com]

2016/6/29 3:15:38 -0700, tim_ellison at uk.ibm.com:
> mark.reinhold at oracle.com wrote on 28/06/2016 22:20:15:
>> 
>> ...
>> 
>> Proposal
>> --------
>> 
>> Drop the agreed resource-encapsulation requirement, which reads:
>> 
>>  Resource encapsulation --- The run-time system must ensure that the
>>  static resource files within a module are directly accessible only by
>>  code within that module.  The existing resource-access APIs should
>>  continue to work as they do today when used to access a module's own
>>  resource files. [2]
>> 
>> ...
>  
> The proposal to drop this requirement leaves no way for a module to encapsulate
> its resources.  Have you considered an alternative that preserves the compatibility
> of existing APIs which I agree is desirable to support existing applications,
> but introduces a module-level resource API that allows those modules that want
> to hide their implementation details?

There are certainly other alternatives; what I proposed is just the
simplest.

One alternative is just to address the two specific use cases.  Make
META-INF/**, WEB-INF/**, and the class file for any class visible to
the caller available via the resource-access APIs, but make all other
resources module-private.

This wouldn't address other use cases that require non-class-file
resources in normal package directories to be available, of which the
Wicket web framework is an example (pointed out by Rafael Winterhalter
[1]).  So a second alternative would be to go further and define a way
to declare which packages of a module are considered to "export" their
resources, similar to what Peter Levart suggested [2]).  Maybe something
like this:

    module com.foo.app {
        requires wicket.core;
        requires wicket.utils;
        publishes com.foo.app.pages.main;
        publishes com.foo.app.pages.aux;
    }

would make resources in the com/foo/app/pages/{main,aux} directories of
the module's artifact available for anyone to load.  By fiat we'd make
everything under {META,WEB}-INF available, for compatibility.  Whether
access to the class files for visible classes should be limited further,
or perhaps solely, by this mechanism, I'm not sure.

So yes, there are some alternatives here.  Thoughts welcome.

- Mark


[1] http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2016-June/000417.html
[2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008355.html