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.
