Proposal: #ResourceEncapsulation and #ClassFilesAsResources

[Paul Benedict]

Dear EG Members,

I would like to formally submit this suggestion for your consideration [1].
The link is what I sent to the "observers" list, but EG members are not
required to read that. Hence the message here.

In summary, I do not believe that unilaterally dropping resource
encapsulation is the right solution. The original proposal encapsulated
resources because they were thought to be implementation details. They
could be -- but not always. It's clear that some resources are meant to be
public while others should be private. So while the former erred by keeping
everything private, the latter is now erring by keeping everything public.
Neither is really acceptable due to their being two legitimate use cases.
There are libraries that do want to share their resources; others do not.

So I would like to propose keeping the current encapsulation requirements
but amending it. My proposal is simply making META-INF an always publicly
accessible folder for resources.

What I don't prefer...

I am not a fan of putting public resources *in* the code location where
classes reside. I understand this is a current pattern [1], but I believe
that pattern has relied on the assumption resources are public. Given that
Jigsaw does change assumptions, I find it perfectly acceptable to specify
that private resources belong where classes reside and public resources go
in META-INF. It is not technically difficult to replicate the package
structure in META-INF if a framework wishes to organize resources that way.
It's different but not difficult.

I am not a fan of adding more module directives to export resources [2].
This is really not necessary if META-INF can do it. I find adding
additional directives is an unnecessary complication.

[1]
http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2016-June/000412.html
[2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008355.html

Cheers,
Paul