Proposals for some open JPMS issues, #ResourceEncapsulation

David M. Lloyd david.lloyd at redhat.com
Thu Jun 30 11:46:49 UTC 2016


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 
for resources; even the more complex approach I outlined would be better 
than nothing.

[1] 
http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2015-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 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
>

-- 
- DML


More information about the jigsaw-dev mailing list