I created a Jira to track this: https://hibernate.atlassian.net/browse/HHH-12188
On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole <st...@hibernate.org> wrote: > Thanks for investigating this Gunnar. > > Some thoughts inline... > > On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling <gun...@hibernate.org> > wrote: > > >> * JDK 9 comes with an incomplete JTA module (java.transaction), so a >> complete one must be provided via --upgrade-module-path (I'm using the >> 2.0.0.Alpha1 version Tomaz Cerar has created for that purpose) >> > > Do you know if there is a plan to fix this in Java 9? Seems bizarre that > Java 9 expects all kinds of strict modularity from libraries and > applications when the JDK itself can't follow that.. > > > >> * hibernate-jpa-2.1-api-1.0.0.Final.jar can't be used as an automatic >> module, as the automatic naming algorithm stumples upon the numbers (2.1) >> within the module name it derives; I'm therefore using my ModiTect >> tooling ( >> https://github.com/moditect/moditect/) to convert the JPA API JAR into an >> explicit module on the fly >> > > We actually no longer use that artifact as a dependency. Since JPA 2.2, > the EG publishes a "blessed" API jar which is what we use as a dependency. > > > >> * When using ByteBuddy as the byte code provider, a reads relationship >> must >> be added from the user's module towards hibernate.core ("requires >> hibernate.core"). This is due to the usage of >> org.hibernate.proxy.ProxyConfiguration within the generated proxy classes. >> Ideally no dependence to the JPA provider should be needed when solely >> working with the JPA API (as this demo does), but I'm not sure whether >> this >> can be avoided when using proxies (or could we construct proxies in a way >> not requiring this dependence?). >> > > I'm not sure what a decent solution would be here. Ultimately the runtime > needs to be able to communicate with the generated proxies - how else would > you suggest this happen? > > > * When using ByteBuddy as the byte code provider, I still needed to have >> Javassist around, as it's used in ClassFileArchiveEntryHandler. I >> understand that eventually this should be using Jandex, but I'm wondering >> whether we could (temporarily) change it to use ASM instead of Javassist >> (at least when using ByteBuddy as byte code provider, which is based on >> ASM), so people don't need to have Javassist *and* ByteBuddy when using >> the >> latter as byte code provider? This seems desirable esp. once we move to >> ByteBuddy by default. >> > > Yes, Sanne brought this up in Paris and it is something I will look at > prior to a 5.3.0.Final > > > * Multiple methods in ReflectHelper call setAccessible() without checking >> whether the method/field/constructor already is accessible. If we changed >> that to only call setAccessible() if actually needed, people would have to >> be a little bit less permissive in their module descriptor. It'd suffice >> for them to declare "exports com.example.entities to hibernate.core" >> instead of "opens com.example.entities to hibernate.core", unless they >> mandate (private) field access for their entities. >> > > Can you open a Jira for that? > > > >> The demo is very simple (insert and load of an entity with a lazy >> association). If there's anything else you'd like to try out when using >> ORM >> as JPMS modules, let me know or just fork the demo and try it out yourself >> > > IIUC for jars targeting both Java 8 and Java 9 we cannot include a > module-info file. But we need to set the module names - you mentioned > there was a "hinting" process. From what I could glean from searching > (which was oddly not many hits), this is achieved by adding a > `Automatic-Module-Name` entry in the JAR's MANIFEST.MF. Correct? > > Also, IIRC we agreed with `org.hibernate.orm` as the base for all ORM > module names, so we'd have: > > - org.hibernate.orm.c3p0 > - org.hibernate.orm.core > - ... > > > > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
