I'll try to jump in. I'm mainly providing an external point of view though, since I didn't seriously follow the progress of Java 9.
If I understood correctly, modules containing entities would not need to be weak; they *could* be, as a quick solution to migrating to Java 9, but ultimately the clean way of (re-)writing them would be: module foo.bar { exports private com.foo.bar.model; // Exports to anyone, including hibernate.* requires javax.jpa; } (Assuming all classes needed by Hibernate are in `com.foo.bar.model`) Then public classes of package `com.foo.bar.model` would be exported to any module, and additionally package-protected classes from this package could be made accessible by anyone using `AccessibleObject::setAccessible`. Which seems to solve the issue at least in principle. What I'm not sure about is if it couldn't be even stricter by using a qualified export : module foo.bar { exports private com.foo.bar.model to hibernate.entitymanager; exports private com.foo.bar.model to hibernate.core; requires javax.jpa; } It has the advantage of not disclosing private code to the entire world, but the disadvantage of referring to the JPA implementation explicitely, which is a shame. In an ideal world, it would be awesome to be able to not reference Hibernate at all (as below) and still reduce the visibility of the "private" package to only a select few modules. It doesn't seem to be possible, and I guess the syntax below is wrong for many reasons. Not the least being that there's no way for the JVM to connect the dots between JPA and Hibernate. module foo.bar { exports private com.foo.bar.model to javax.jpa; // Won't work requires javax.jpa; } In the end, isn't the issue also about the lack of a concept of "module interface", which "implementation modules" may implement? I mean, here, a developer may not want to say "I'm using Hibernate", just "I'm using JPA", and let the consumer of the module choose the actual JPA implementation. It would be a bit like the `uses` and `provides` keywords, except we would be referring to entire modules instead of classes. I guess that, of course, the full definition of such a feature might get quite complex depending on what it provides exactly. Yoann Rodière <yo...@hibernate.org> Hibernate NoORM Team On 16 September 2016 at 19:27, Emmanuel Bernard <emman...@hibernate.org> wrote: > No one ? > > > On 13 Sep 2016, at 10:19, Emmanuel Bernard <emman...@hibernate.org> > wrote: > > > > Hi all, > > > > Sanne kindly pointed out to me the latest proposal by the OpenJDK team > > around JDK 9 module and how they would handle frameworks needing access > > to non exported types (Hibernate, dependency injection, etc). > > > > If you are remotely into JDK9, please read it and provide feedback. > > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/ > 2016-September/000390.html > > > > It's better than before for sure. It feels to me that most applications > > (the core of it) will end up being a weak module for this to work > > though. I'm not sure whether it is good or bad, at least a isolation > > concious person has the choice. > > > > export private some.package; > > > > Is essentially equivalent to what you can do for a given package in Java > > 8. > > What I am less clear about is what relation Hibernate * projects really > > need with a module containing the entities. Do we still this proposal > > still mandates to use > > > > requires hibernate.entitymanager; > > requires hibernate.core; > > > > in the targeted module? > > > > Or would this be a usable module > > > > module foo.bar { > > exports private com.foo.bar.model; > > requires javax.jpa; > > // requires hibernate.entitymanager/core; no longer needed thanks > to export private? > > } > > > > Mark proposes that in a container (EE or anything controlling module > loading > > really), the container adds dynamically the addExports to the relevant > > framework. But that looks like a solution to limit exports private > > implications. > > > > Comments? > > > > Emmanuel > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev