Hi, The proposal for #ResourceEncapsulation plans to drop the resource-encapsulation requirement. Have you thought about a "middle ground" ? Possibility 1: resources in a module could be divided in two groups: always accessible: resources in "root" package and special directories such as META-INF/**, WEB-INF/** (dilemma: how to define "special directories") governed by qualified/unqualified package exports: other resources located in module subdirectories mapped to package names Possibility 2: access to classes is by default restricted and explicitly enabled by package exports. Access to resources could be governed by special module-info syntax, modeled for example by file patterns used in ANT build tool: module m1 { requires ... exports ... uses ... provides ... exportsResources *, META-INF/**, WEB-INF/**; } Automatic modules would "export" all resources. Module readability would not play any role in accessing the resources (as it is the case with accessing classes by reflection). Regards, Peter On 06/28/2016 11:47 PM, mark.reinhold@oracle.com wrote:

FYI, I've just posted proposals for some of the open issues in the draft JPMS specification, including:

#CompileTimeDependences #ReflectiveAccessToNonExportedTypes #ModuleAnnotations and #ModuleDeprecation #ResourceEncapsulation and #ClassFilesAsResources #ReflectiveAccessByInstrumentationAgents #BootstrapClassLoaderSearchInJVMTI #CustomizableAutomaticModuleNameMapping

Links to the proposals are available in the issue summary [1].

Comments and discussion are welcome here on jigsaw-dev but, as usual, the best way to ensure that the EG sees any specific comment is to send it to the EG's "suggestion box" list, jpms-spec-comments [2].

If you comment on one of these proposals, via any channel, please include the hashtag of the relevant issue(s) in the subject line of your message, to simplify tracking. Thanks!

- Mark

[1] http://openjdk.java.net/projects/jigsaw/spec/issues/ [2] http://mail.openjdk.java.net/mailman/listinfo/jpms-spec-comments