Proposal: #ReflectiveAccessToNonExportedTypes: `exports dynamic`

[Alan Bateman]

On 02/07/2016 23:50, Nicolai Parlog wrote:
>   Hi Paul,
>
> either I'm misunderstanding you or one of us misunderstood the proposal.
>
>> 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?
> You seem to be talking about qualified exports, which let you export
> packages _to_ a specific module (at compile and at run time). Dynamic
> exports, on the other hand, will export packages to every module
> (although I assume there would also be qualified dynamic exports) but
> only at run time.
That's right and it shouldn't matter if Hibernate is using core 
reflection, method handles, or spinning code at runtime. In the case of 
the latter two then the framework will need to arrange the readability 
but that should be straight-forward to do as part of upgrading the 
framework to support modules.

The other point that I don't see mentioned in this thread is that some 
of the cases should be checkable at build time. If I have @Inject on a 
member in a non-exported package then it would be possible to catch this 
at build time. Same thing with configuration files where the types are 
listed in the configuration.

-Alan