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.... [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008355.html Cheers, Paul