Proposal: #ReflectiveAccessToNonExportedTypes: `exports dynamic`
alex.buckley at oracle.com
Thu Jun 30 23:12:37 UTC 2016
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
> 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.
More information about the jpms-spec-observers