Follow-up question on new proposals for #ResourceEncapsulation & #ClassFilesAsResources

[Martin Lehmann]

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-bounces at openjdk.java.net] On Behalf Of
Mark Reinhold
Sent: Monday, September 12, 2016 5:20 PM
To: jigsaw-dev at 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