Proposal: #ReflectiveAccessToNonExportedTypes: `exports dynamic`

[Alex Buckley]

On 6/30/2016 3:20 PM, Rafael Winterhalter wrote:
> I do not think that shielding internals is a problem with regards to
> reflection. You want to shield internals in order to not break dependants
> by prohibiting their existance. With reflection, you do however typically
> react to the actual implementation by discovering it at runtime. If your
> use pattern was fixed, you would always require a static dependency over
> reflection in the first place. I do neither think that reflection only
> interests internals. For example, maybe you use Hibernate for your
> persistance layer without exposing those DTOs from your module. The problem
> is that you invert responsibilities. I do not care about how Hibernate
> works as long as it does work. Almost any library uses reflection and I
> would not want to dig into implementation details to find out how to set up
> my dynamic exports.

I agree that no-one should have to look at a framework's implementation 
to figure out what to export dynamically. It's up to the framework's 
specification to describe where it plans to inspect the internals of 
modules requiring the framework. In Stephen's example, the Strata 
specification did that admirably.

That said, as soon as you mention inverting responsibilities, it becomes 
clear that services are the answer. Rather than the framework reflecting 
over the internals of a user module to discover suitable classes, the 
framework should define a service interface and a user module should 
provide a service implementation. It seems like this is a style of OO 
programming that has passed many framework developers by, but there are 
some big benefits:

1. The user module knows statically that it's following the idiom 
expected by the framework. There's no "oops, I forgot to name my static 
field correctly in the DTO class."

2. The framework delegates the boring work of discovery to 
ServiceLoader. There's no need for framework code to crawl the classpath 
or modulepath looking for assignable classes.

3. The framework, by no longer working with Class objects, avoids the 
deathly assumption that it has visibility of the same classes as the 
user module.

Alex

> I want to require a module and hopefully the compiler
> tells me about anything that's wrong. Reflection access errors would only
> be an awkward side effect that can be avoided by not applying modules
> alltogether. I think this limitation would therefore hurt Java 9 adoption.
>