Proposal: #ReflectiveAccessToNonExportedTypes: `exports dynamic`

[Stephen Colebourne]

On 1 July 2016 at 00:12, Alex Buckley <alex.buckley at oracle.com> wrote:
> 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

Not really. The original frameworks in Java operated this way, with
specific interfaces that applications had to implement. Spring and
Ruby on Rails changed this, with a string desire for non-intrusive
frameworks, POJOs and configuraton by convention.

So, while I understand the benefits of a ServiceLoader approach, I
think it is important to accept that it is very unpopular with
framework authors over the last 10-15 years. Annotations, reflection
and agents are where framework design is. (ServiceLoader also seems to
be a rather arcane API)

I do think Paul's arguments hit the nail on the head.  Even if you
could work out which packages need exposure by reflection, you would
be doing so for today, and highly likely to cause yourself problems in
the future. This is especially so for open source libraries.

To give an example of a potential problem, if application A depends on
library B which today has reflection, A could declare a dynamic export
to B. But if B is later rewritten to use a third party library C for
reflection, then A's export is no longer valid, and the later version
of B will not work.

I also note that it is inconsistent that the proposed resolution of
this issue is different to that for #ResourceEncapsulation. With
resources, the proposal is to allow access to all resources. Yet here,
there is an attempt to limit reflection. The resolution to
#ReflectionWithoutReadability was good, but to be effective it also
needs open reflective access.

FWIW, I understand the fears of those that are burned by reflective
access making a private API effectively public. But issues like that
come about through a failure of the library author(s) to provide the
correct API, not a failure of the user.

In summary, if this feature remains, I fear my "Java 9 best practices"
talk will have to recommend marking all packages as "dynamic".

Stephen