More proposals for open issues
mark.reinhold at oracle.com
Mon Sep 12 15:07:01 UTC 2016
I'm about to post proposals, or revised proposals, for the following
#ReflectiveAccessToNonExportedTypes & #AwkwardStrongEncapsulation
#ResourceEncapsulation & #ClassFilesAsResources
I'll update the issue list  immediately thereafter with links to the
Be warned that the proposal for #ReflectiveAccessToNonExportedTypes and
#AwkwardStrongEncapsulation makes significant changes to the syntax and
semantics of module declarations. The latter issue is a new issue,
reported to me in person at JVMLS last month by Martin Buchholz and in
e-mail by 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 JSR. 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.
As usual, if you comment on one of these proposals then please either
reply on the existing thread or else include the hashtag of the relevant
issue(s) in the subject line of a new thread, to simplify tracking.
I look forward to your feedback!
More information about the jpms-spec-experts