Proposals for some open JPMS issues, #ResourceEncapsulation

Peter Levart peter.levart at
Mon Aug 15 08:47:41 UTC 2016

Hi Paul,

Even if there were any resource visibility controls implemented at the
module level, I would expect automatic modules to make all resources
visible, just like they export all packages. So no changes to automatic
modules behavior.



On Aug 14, 2016 23:05, "Paul Bakker" < at> wrote:

I have been testing migrations of "typical" applications (e.g.
Spring/Hibernate) using Automatic Modules. The application code is migrated
to modules, while libraries are used as Automatic Modules.
The dropped resource constraints make a huge difference. With a JDK build
that still has the resource constraints there are a lot of little, but
important, things that don't work well with existing frameworks. In many
cases this would require changes to the frameworks themselves. With the
resource constraints dropped, migrations towards modules go very smoothly.
I'm not suggesting that some middle ground wouldn't be useful, but at least
the dropped constraints is better than keeping them.


> On 10 Aug 2016, at 18:18, Juergen Hoeller <jhoeller at> wrote:
> From Spring's side, dropping resource encapsulation would be the easiest
> way out. That said, I can imagine some middle ground as well since we
> effectively only need access to META-INF resources.
> For a recent example, is about
> finding schema declarations behind Spring XML namespaces which currently
> only works in classpath mode (on mainline JDK 9).
> Juergen
> On Thu, Jun 30, 2016 at 1:46 PM, David M. Lloyd <david.lloyd at>
> wrote:
>> On 06/30/2016 06:13 AM, Peter Levart wrote:
>>> Hi,
>>> The proposal for #ResourceEncapsulation plans to drop the
>>> resource-encapsulation requirement. Have you thought about a "middle
>>> ground" ?
>> I went into a lot of detail on this topic last year [1] but nothing much
>> came of it.  I do agree that it would be good to have a better approach
>> resources; even the more complex approach I outlined would be better than
>> nothing.
>> [1]
>> 015-February/000033.html
>> (eom)
>>> 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 at 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]
>>>> [2]
>> --
>> - DML

More information about the jigsaw-dev mailing list