Proposal: #ReflectiveAccessToNonExportedTypes (revised) & #AwkwardStrongEncapsulation: Weak modules & private exports

[Sander Mak]

> On 13 Sep 2016, at 00:58, Stephen Colebourne <scolebourne at joda.org> wrote:
> 
> 
> 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.


Sander