Proposal: #ReflectiveAccessToNonExportedTypes: `exports dynamic`

[Paul Benedict]

Since Hibernate is a popular example for this topic, let's talk about it.

First, when I build JPA applications, I do have an implementation use in
mind (Hibernate, EclipseLink, etc.), but my code is standardized JPA as
much as possible. So if I am going to publish my JPA model and I want my
private types reflected to be loaded as entities, who am I going to export
it too?

Well I certainly am not going to export it to "jpa" because that's just a
specification...

The next logical answer would be the "hibernate" module, but now I'm
gambling on knowing the internals of Hibernate... I have used Hibernate
professionally for several years, but, off the top of my head, I honestly
couldn't tell you if HIbernate has its own reflection routines or if it
delegates it to third party libraries like "cglib" and "javassist". My gut
tells me it's the latter, but don't quote me on it :-)

So now "dynamic" has put me in a pickle. All I really want to do is have
Hibernate access my private types for JPA, but I have to roll several dice
and pray to be right:
(1) I got to know if Hibernate does its reflection or not
(2) Does Hibernate delegate to third party reflection libraries?
(3) Are the third party reflection libraries pluggable?
(4) What is going to happen to my code if Hibernate alters its reflection
mechanism?

#4 is pretty important, actually. Tools have been known to shade some of
their third party dependencies. So while, for example, Hibernate may rely
on "cglib" or "javassist" today, there is a possibility those may be shaded
and brought in and another package name in a future version. I've seen
those discussions. I am not implying what was or wasn't decided, but just
it's a possibility.

I just don't see a point in creating such a risky situation for myself. I'd
rather just have everything exported all the time to every module if this
is the way reflection is going.


Cheers,
Paul

On Fri, Jul 1, 2016 at 5:20 AM, Jochen Theodorou <blackdrag at gmx.org> wrote:

>
>
> On 01.07.2016 11:15, Rafael Winterhalter wrote:
> [...]
>
>> Finally, I do not believe the service loader API offers an adequate
>> alternative to many use-cases of reflection (while it can perfectly
>> substitute some of them).  Many state-of-the art libraries actually
>> intentionally offer POJO approaches without requiring their users to
>> create
>> interfaces for any shared interaction. I do not think that a gentle push
>> into a direction that contradicts most existing Java libraries would be a
>> taken well by the people implementing this software and in the end, the
>> module system will be as successful as its adoption. I rather see people
>> finding new ways around restrictions to keep things simple (for
>> themselves).
>>
>
> even in the cases the service API is a replacement, the usage of the
> library will change and a breaking change is forced.
>
> For all these reasons I do not think that it is a good idea to limit
>> reflection to exported packages.
>>
>
> or people will start just exporting everything.
>
> bye Jochen
>