Proposal: #ResourceEncapsulation and #ClassFilesAsResources

[Rafael Winterhalter]

I just checked a customer application that uses Apache Wicket. The
application has a widget (Maven) module that currently includes 173
packages where each package contains such files that would need to be
exported explicitly. I do not think that exporting each package would be a
realistic solution (you can only find out if your forgot a single package
at runtime) and most likely, the application would opt-out of
modularization. (I do not claim this is well-organized software, but in my
experience most enterprise applications are structured rather "organic"
after "urgent" customer demands.)

My main concern is that with explicit exports, some people would easily
adapt "publishing all resources" as a strange best practice. (Similarly to
how I argued with regards to reflection:
http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2016-July/000451.html).
Also - if the proposal would include class files - this would again break
libraries like Javassist (
http://mvnrepository.com/artifact/org.javassist/javassist/usages) or Byte
Buddy (http://mvnrepository.com/artifact/net.bytebuddy/byte-buddy/usages)
and all of their users. As a heavy user of Javaagents (I contracted with
different APM and tools vendors), I can only warn that this would be a huge
set-back to the platform.

In my eyes, the main advantage of shielding modules-bundled resources is to
avoid conflicts, e.g. the duplicate existance of some file
"/properties.json" in two modularized jars where the file is only relevant
to each particular module. This problem is however already solved by the
added Module::getResourceAsAStream API where I can explicitly request "my"
file from "my" module. As for inter-module interaction, I do not think it
is feasible to anticipate all established use-patterns and I want to
suggest to not limit visibility when reading resources via a ClassLoader.

2016-07-01 1:52 GMT+02:00 <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
>