Hi all, I have a follow-up question on the new proposal on #ResourceEncapsulation, which states: > The effective package name of a resource named by the string > `"/foo/bar/baz"`, e.g., is 'foo.bar'.
The idea of using resource paths as "effective package names" definitely makes sense to me. Sounds like a pragmatic way of getting this important requirement finally done. Great! But with the new module system, classes on the unnamed package are no longer allowed. The compiler rejects them with "error: unnamed package is not allowed in named modules". I am wondering what's going to happen with resources on the "unnamed path", so to say. It's not uncommon that resources like a "log4j.properties" are put and searched on the top-level path - i.e. the equivalent of the unnamed (class) package. What will happen to that at compile time (probably nothing?), at packaging time (jar does complain?) and at runtime? Thanks in advance, cheers, Martin -----Original Message----- From: jigsaw-dev [mailto:jigsaw-dev-boun...@openjdk.java.net] On Behalf Of Mark Reinhold Sent: Monday, September 12, 2016 5:20 PM To: jigsaw-dev@openjdk.java.net Subject: More proposals for open JPMS issues FYI, I've just posted new or revised proposals for some of the open issues in the JPMS specification: #ReflectiveAccessToNonExportedTypes & #AwkwardStrongEncapsulation http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/0003 90.html #AddExportsInManifest http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/0003 91.html #ResourceEncapsulation & #ClassFilesAsResources http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/0003 92.html #VersionsInModuleNames http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/0003 93.html #ClassLoaderNames http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/0003 94.html #ServiceLoaderEnhancements http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/0003 95.html Links to the proposals are also available in the issue summary [1]. The first proposal, for #ReflectiveAccessToNonExportedTypes and #AwkwardStrongEncapsulation, is likely to be of the broadest interest since it makes significant changes to the syntax and semantics of module declarations. The latter issue is a new issue, reported by Martin Buchholz and Aleksey Shipilev, and is summarized thus: #AwkwardStrongEncapsulation --- A non-public element of an exported package can still be accessed via the `AccessibleObject::setAccessible` method of the core reflection API. The only way to strongly encapsulate such an element is to move it to a non-exported package. This makes it awkward, at best, to encapsulate the internals of a package that defines a public API. The present design suffers this limitation due to an earlier compromise made to accommodate reflective access by frameworks, but experience has now shown that to be a problematic approach. It would be unfortunate indeed to bake this limitation into the module system for all time: It would make it much more difficult for developers to strongly encapsulate the internals of their own modules, yet enabling such encapsulation is one of the primary goals of this project. Thus this new proposal, which introduces the concepts of weak modules and private exports and removes the previously-proposed notion of dynamic exports. This has taken some time to work out but, in the end, appears to achieve a better balance of usability, ease of migration, and expressive power. 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 its hashtag in the subject line of your message to simplify tracking. - Mark [1] http://openjdk.java.net/projects/jigsaw/spec/issues/ [2] http://mail.openjdk.java.net/mailman/listinfo/jpms-spec-comments
