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