Another thing I was noticing was an annoying minor difference between the OSGi bundle name and the Java 9 module name:
Automatic-Module-Name: org.hibernate.orm.core Bundle-SymbolicName: org.hibernate.core Does it make sense to adjust the OSGi bundle name to follow the module naming? On Sat, Dec 23, 2017 at 8:47 AM Steve Ebersole <st...@hibernate.org> wrote: > 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
