2017-12-22 23:07 GMT+01:00 Steve Ebersole <st...@hibernate.org>: > 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.. >> > The "java.transaction" module of the JDK is marked with @Deprecated(forRemoval=true) as of Java 9, but I don't know when the removal will happen. There's JEP 320 for this ( http://openjdk.java.net/jeps/320), which also describes why the module exists in its current form. It's not scheduled for Java 10 currently, and given the latter is in rampdown already, I wouldn't expect this removal to happen before Java 11.
>> >>> * 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. >> > Ah, yes, very nice. That one already defines an explicit module name ("java.persistence") via the Automatic-Module-Name manifest entry. > >> >>> * 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? >> > Not sure either. Maybe we could generate a dedicated interface into the user's module and then inject a generated implementation -- living within the ORM module -- of that interface into the entities. Worth some tinkering I reckon. > >> * 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 >> > Excellent. > >> >> * 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? >> > Done: https://hibernate.atlassian.net/browse/HHH-12189. >> >>> 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? >> > Yes, exactly that's the mechanism. Jason Greene is working on a document with recommendations around naming patterns, I hope it'll be published soon. >> 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
