Feedback on proposal for #ReflectiveAccessToNonExportedTypes

Stephane Epardaud stef at
Thu Jul 14 09:56:30 UTC 2016

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.

Now, if we want to qualify the export, it's not entirely clear to whom 
it should be exported. We could say that it has to be exported to the 
module providing the IoC annotation (JPA for @Entity), but it's likely 
not useful because it's implementations of that lib that would use 
reflection (Hibernate). If the module system was extended to provide 
"virtual" modules (for example, Hibernate would be marked as "providing" 
JPA), then we could treat Hibernate as inheriting the "requires dynamic" 
permissions of the modules it provides (JPA) and so it would be able to 
reflect over types exported to JPA.

Virtual modules is one of the most wanted features in Ceylon modularity, 
but we haven't implemented it yet, for lack of time resolving some of 
the issues it raises. Though I don't think virtual modules are required 
for this feature to be useful.

I don't think it makes much sense to add Hibernate or other JPA 
implementations as "friend modules" to the JPA module, as that would 
prevent other implementations, but perhaps an annotation (say, 
@InheritDynamicExports) on the Hibernate module (or rather, on its 
import of the JPA module) would mark it as inheriting dynamic export 
permissions from the JPA module? This way the VM would let Hibernate 
reflect over my model types even though they're only exported 
dynamically to JPA. A SecurityManager would be allowed to restrict that, 
of course.

More information about the jigsaw-dev mailing list