More proposals for open JPMS issues

[Mark Reinhold]

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/000390.html
  #AddExportsInManifest
    http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000391.html
  #ResourceEncapsulation & #ClassFilesAsResources
    http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000392.html
  #VersionsInModuleNames
    http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000393.html
  #ClassLoaderNames
    http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000394.html
  #ServiceLoaderEnhancements
    http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000395.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