Proposal: #ReflectiveAccessToNonExportedTypes (revised) & #AwkwardStrongEncapsulation: Weak modules & private exports
paul.bakker at luminis.eu
Tue Sep 13 07:29:43 UTC 2016
Another +1 for the return of dynamic exports. Frameworks using reflection
are such a common case that if dynamic exports are not available, users
will either create weak modules for all their code, or they have to export
packages that they would rather not export. While "dynamic export" is still
not true encapsulation, it is a nice tradeoff between compatibility with
existing frameworks and encapsulation.
The exact keyword is less important to me. "dynamic" made sense to me, so
Both "weak" modules and the alternative proposed by Stephen would be ok. I
somewhat like "weak" because it communicates that it is probably not an end
solution, but a migration step instead.
On Tue, Sep 13, 2016 at 8:33 AM Sander Mak <sander.mak at luminis.eu> wrote:
> > On 13 Sep 2016, at 00:58, Stephen Colebourne <scolebourne at joda.org>
> > For the weak modules, the proposal does not provide a way to have
> > packages exposed for runtime use, but not hidden at compile time.
> > Given the benefits of hiding internal classes from IDEs, this seems
> > rather unfortunate.
> Major +1. With private exports, we need to rely on will-power and
> out-of-band knowledge again to prevent people from shooting themselves in
> the foot. Given the prevalence of applications using dependency injection
> frameworks (hence using `exports private), this is a non-trivial concession.
> > Here is my counter proposal, hopefully a
> > relatively small conceptual change:
> Not sure whether introducing a new top-level keyword (exposes) is better
> than adding a modifier keyword to exports. As was the case with `exports
> dynamic`, but a better name might be `exports runtime` since that's how we
> are referring to its effects in this whole discussion. For the rest, I
> agree with the gist of the counter proposal.
More information about the jigsaw-dev