I already did a PR for the `Automatic-Module-Name` yesterday and added you as a reviewer. when you get a chance...
On Sat, Dec 23, 2017 at 8:36 AM Gunnar Morling <gun...@hibernate.org> wrote: > 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
