Feedback on proposal for #ReflectiveAccessToNonExportedTypes

[Jason Greene]

> On Jul 14, 2016, at 4:56 AM, Stephane Epardaud <stef at epardaud.fr> wrote:
> 
> So how about a Java Language annotation (say, @RequiresExport) that we could place on IoC framework annotation definitions (say, @Entity, from JPA) that would tell the compiler that any type annotated with @Entity must be exported?
> 
> That would solve the issue of making sure that users would not be surprised by access exceptions at run-time when Hibernate can't use reflection on their JPA entities. The compiler would check that, and IDEs would have quick-fixes to add the required (dynamic) exports to the module descriptor from such an error.

That helps the boilerplate issue, but only for annotation frameworks. Configuration based IoC, and other dynamic use cases (e.g. serialization) would run into trouble.


> Now, if we want to qualify the export

If exports are still going to be used to restrict reflective access (I still argue this approach is a poor fit and does more harm than good), then it has to somehow be qualified, otherwise you cause users are going to have conflicts. 

> it's not entirely clear to whom it should be exported.

Right a key point I make in my argument is that a module is not in a position to know who can enhance it. The whole value of dynamic programming is that it can actually be dynamic, and explicit static module qualification greatly limits dynamic behavior. There has to at least be an indirection of some sort for the qualification, and that indirection needs to be expandable at runtime (some form of runtime enlistment).

Since IoC patterns are pervasive (more than a majority of all server side Java applications), I argue this sort of dynamic placeholder export should just be on by default (it’s the more common case).

Once all of that is done, it’s not clear how it is any better than a simple runtime permission.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat