* 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)

* 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

* 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?).

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.

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.

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

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 <steve(a)hibernate.org&gt; wrote: > Thanks for investigating this Gunnar. > > Some thoughts inline... > > On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling <gunnar(a)hibernate.org&gt; > 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 > - ... > > > > >

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 <gunnar(a)hibernate.org&gt; wrote: > 2017-12-22 23:07 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >> 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 <steve(a)hibernate.org&gt; >> wrote: >> >>> Thanks for investigating this Gunnar. >>> >>> Some thoughts inline... >>> >>> On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling <gunnar(a)hibernate.org&gt; >>> 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 >>> - ... >>> >>> >>> >>> >>> >>

+1 from me on making them consistent. In practice, Bundle-SymbolicName isn't used for much, other than a guaranteed unique identifier. One of the Karaf guys pointed out that Bundle-SymbolicName is used to link a fragment bundle to its host bundle, but we've been able to avoid fragments like the plague on purpose. In practice, most users should be pulling in and interacting with our bundles purely through Maven artifacts or our features.xml, so a change would largely be unnoticed. We still might consider holding off doing that until at least a minor version change, since there is a potential issue for any tooling that might be relying on that (logging/auditing, etc.)... On 12/23/17 11:38 PM, Steve Ebersole wrote: > 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 <steve(a)hibernate.org&gt; 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 <gunnar(a)hibernate.org&gt; >> wrote: >> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>> >>>> 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 <steve(a)hibernate.org&gt; >>>> wrote: >>>> >>>>> Thanks for investigating this Gunnar. >>>>> >>>>> Some thoughts inline... >>>>> >>>>> On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling <gunnar(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

After tweaking this, here is what I have... Manifest-Version: 1.0 Created-By: 1.8.0_121 (Oracle Corporation) Main-Class: org.hibernate.Version Specification-Title: hibernate-core Specification-Version: 5.3 Specification-Vendor: Hibernate.org Implementation-Title: hibernate-core Implementation-Version: 5.3.0.SNAPSHOT Implementation-Vendor-Id: org.hibernate Implementation-Vendor: Hibernate.org Implementation-Url: http://hibernate.org Automatic-Module-Name: org.hibernate.orm.core Bundle-ManifestVersion: 2 Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))" Tool: Bnd-3.4.0.201707252008 Bundle-SymbolicName: org.hibernate.orm.core Bundle-Version: 5.3.0.SNAPSHOT Bundle-Name: hibernate-core Bundle-Description: A module of the Hibernate O/RM project Bundle-Vendor: Hibernate.org Bundle-DocURL: http://www.hibernate.org/orm/5.3 Bnd-LastModified: 1513615321000 Import-Package: ... Export-Package: ... Which looks great to me... On Wed, Dec 27, 2017 at 3:39 PM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > I had intended this for 5.3 which hasn't even gone Beta yet (we wont have > an Alpha). > > On Wed, Dec 27, 2017 at 3:38 PM Brett Meyer <brett(a)hibernate.org&gt; wrote: > >> +1 from me on making them consistent. In practice, Bundle-SymbolicName >> isn't used for much, other than a guaranteed unique identifier. One of >> the Karaf guys pointed out that Bundle-SymbolicName is used to link a >> fragment bundle to its host bundle, but we've been able to avoid >> fragments like the plague on purpose. >> >> In practice, most users should be pulling in and interacting with our >> bundles purely through Maven artifacts or our features.xml, so a change >> would largely be unnoticed. >> >> We still might consider holding off doing that until at least a minor >> version change, since there is a potential issue for any tooling that >> might be relying on that (logging/auditing, etc.)... >> >> >> On 12/23/17 11:38 PM, Steve Ebersole wrote: >> > 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 <steve(a)hibernate.org&gt; >> 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 <gunnar(a)hibernate.org&gt; >> >> wrote: >> >> >> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> >>> >> >>>> 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 <steve(a)hibernate.org >> > >> >>>> wrote: >> >>>> >> >>>>> Thanks for investigating this Gunnar. >> >>>>> >> >>>>> Some thoughts inline... >> >>>>> >> >>>>> On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling < >> gunnar(a)hibernate.org&gt; >> >>>>> 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(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >

After tweaking this, here is what I have... Manifest-Version: 1.0 Created-By: 1.8.0_121 (Oracle Corporation) Main-Class: org.hibernate.Version Specification-Title: hibernate-core Specification-Version: 5.3 Specification-Vendor: Hibernate.org Implementation-Title: hibernate-core Implementation-Version: 5.3.0.SNAPSHOT Implementation-Vendor-Id: org.hibernate Implementation-Vendor: Hibernate.org Implementation-Url: http://hibernate.org Automatic-Module-Name: org.hibernate.orm.core Bundle-ManifestVersion: 2 Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))" Tool: Bnd-3.4.0.201707252008 Bundle-SymbolicName: org.hibernate.orm.core Bundle-Version: 5.3.0.SNAPSHOT Bundle-Name: hibernate-core Bundle-Description: A module of the Hibernate O/RM project Bundle-Vendor: Hibernate.org Bundle-DocURL: http://www.hibernate.org/orm/5.3 Bnd-LastModified: 1513615321000 Import-Package: ... Export-Package: ... Which looks great to me... On Wed, Dec 27, 2017 at 3:39 PM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > I had intended this for 5.3 which hasn't even gone Beta yet (we wont have > an Alpha). > > On Wed, Dec 27, 2017 at 3:38 PM Brett Meyer <brett(a)hibernate.org&gt; wrote: > >> +1 from me on making them consistent. In practice, Bundle-SymbolicName >> isn't used for much, other than a guaranteed unique identifier. One of >> the Karaf guys pointed out that Bundle-SymbolicName is used to link a >> fragment bundle to its host bundle, but we've been able to avoid >> fragments like the plague on purpose. >> >> In practice, most users should be pulling in and interacting with our >> bundles purely through Maven artifacts or our features.xml, so a change >> would largely be unnoticed. >> >> We still might consider holding off doing that until at least a minor >> version change, since there is a potential issue for any tooling that >> might be relying on that (logging/auditing, etc.)... >> >> >> On 12/23/17 11:38 PM, Steve Ebersole wrote: >> > 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 <steve(a)hibernate.org&gt; >> 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 <gunnar(a)hibernate.org&gt; >> >> wrote: >> >> >> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> >>> >> >>>> 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 <steve(a)hibernate.org >> > >> >>>> wrote: >> >>>> >> >>>>> Thanks for investigating this Gunnar. >> >>>>> >> >>>>> Some thoughts inline... >> >>>>> >> >>>>> On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling < >> gunnar(a)hibernate.org&gt; >> >>>>> 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(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >

Maybe this is similar to the problems we've had with the WildFly hibernate-orm-moudles stuff - versions of karaf/aries/etc not yet supporting EE8 techs (JPA 2.2, CDI 2.0, etc)? On Thu, Dec 28, 2017 at 11:56 AM Steve Ebersole <steve(a)hibernate.org <mailto:steve@hibernate.org>> wrote: Brett, after making these changes the osgi tests now fail[1] with a RMI connection error which I cannot decipher.  Could you see if you can understand the problem? Thanks [1] http://ci.hibernate.org/job/hibernate-orm-master-h2-main/942/testReport/j... On Thu, Dec 28, 2017 at 9:06 AM Steve Ebersole <steve(a)hibernate.org <mailto:steve@hibernate.org>> wrote: After tweaking this, here is what I have... Manifest-Version: 1.0 Created-By: 1.8.0_121 (Oracle Corporation) Main-Class: org.hibernate.Version Specification-Title: hibernate-core Specification-Version: 5.3 Specification-Vendor: Hibernate.org Implementation-Title: hibernate-core Implementation-Version: 5.3.0.SNAPSHOT Implementation-Vendor-Id: org.hibernate Implementation-Vendor: Hibernate.org Implementation-Url: http://hibernate.org Automatic-Module-Name: org.hibernate.orm.core Bundle-ManifestVersion: 2 Require-Capability: osgi.ee <http://osgi.ee>;filter:="(&(osgi.ee <http://osgi.ee>=JavaSE)(version=1.8))" Tool: Bnd-3.4.0.201707252008 Bundle-SymbolicName: org.hibernate.orm.core Bundle-Version: 5.3.0.SNAPSHOT Bundle-Name: hibernate-core Bundle-Description: A module of the Hibernate O/RM project Bundle-Vendor: Hibernate.org Bundle-DocURL: http://www.hibernate.org/orm/5.3 Bnd-LastModified: 1513615321000 Import-Package: ... Export-Package: ... Which looks great to me... On Wed, Dec 27, 2017 at 3:39 PM Steve Ebersole <steve(a)hibernate.org <mailto:steve@hibernate.org>> wrote: I had intended this for 5.3 which hasn't even gone Beta yet (we wont have an Alpha). On Wed, Dec 27, 2017 at 3:38 PM Brett Meyer <brett(a)hibernate.org <mailto:brett@hibernate.org>> wrote: +1 from me on making them consistent.  In practice, Bundle-SymbolicName isn't used for much, other than a guaranteed unique identifier.  One of the Karaf guys pointed out that Bundle-SymbolicName is used to link a fragment bundle to its host bundle, but we've been able to avoid fragments like the plague on purpose. In practice, most users should be pulling in and interacting with our bundles purely through Maven artifacts or our features.xml, so a change would largely be unnoticed. We still might consider holding off doing that until at least a minor version change, since there is a potential issue for any tooling that might be relying on that (logging/auditing, etc.)... On 12/23/17 11:38 PM, Steve Ebersole wrote: > 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 <steve(a)hibernate.org <mailto:steve@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 <gunnar(a)hibernate.org <mailto:gunnar@hibernate.org>> >> wrote: >> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole <steve(a)hibernate.org <mailto:steve@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 <steve(a)hibernate.org <mailto:steve@hibernate.org>> >>>> wrote: >>>> >>>>> Thanks for investigating this Gunnar. >>>>> >>>>> Some thoughts inline... >>>>> >>>>> On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling <gunnar(a)hibernate.org <mailto:gunnar@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(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/hibernate-dev

After tweaking this, here is what I have... Manifest-Version: 1.0 Created-By: 1.8.0_121 (Oracle Corporation) Main-Class: org.hibernate.Version Specification-Title: hibernate-core Specification-Version: 5.3 Specification-Vendor: Hibernate.org Implementation-Title: hibernate-core Implementation-Version: 5.3.0.SNAPSHOT Implementation-Vendor-Id: org.hibernate Implementation-Vendor: Hibernate.org Implementation-Url: http://hibernate.org Automatic-Module-Name: org.hibernate.orm.core Bundle-ManifestVersion: 2 Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))" Tool: Bnd-3.4.0.201707252008 Bundle-SymbolicName: org.hibernate.orm.core Bundle-Version: 5.3.0.SNAPSHOT Bundle-Name: hibernate-core Bundle-Description: A module of the Hibernate O/RM project Bundle-Vendor: Hibernate.org Bundle-DocURL: http://www.hibernate.org/orm/5.3 Bnd-LastModified: 1513615321000 Import-Package: ... Export-Package: ... Which looks great to me... On Wed, Dec 27, 2017 at 3:39 PM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > I had intended this for 5.3 which hasn't even gone Beta yet (we wont have > an Alpha). > > On Wed, Dec 27, 2017 at 3:38 PM Brett Meyer <brett(a)hibernate.org&gt; wrote: > >> +1 from me on making them consistent. In practice, Bundle-SymbolicName >> isn't used for much, other than a guaranteed unique identifier. One of >> the Karaf guys pointed out that Bundle-SymbolicName is used to link a >> fragment bundle to its host bundle, but we've been able to avoid >> fragments like the plague on purpose. >> >> In practice, most users should be pulling in and interacting with our >> bundles purely through Maven artifacts or our features.xml, so a change >> would largely be unnoticed. >> >> We still might consider holding off doing that until at least a minor >> version change, since there is a potential issue for any tooling that >> might be relying on that (logging/auditing, etc.)... >> >> >> On 12/23/17 11:38 PM, Steve Ebersole wrote: >> > 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 <steve(a)hibernate.org&gt; >> 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 <gunnar(a)hibernate.org > >> >> wrote: >> >> >> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> >>> >> >>>> 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 < steve(a)hibernate.org&gt; >> >>>> wrote: >> >>>> >> >>>>> Thanks for investigating this Gunnar. >> >>>>> >> >>>>> Some thoughts inline... >> >>>>> >> >>>>> On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling < >> gunnar(a)hibernate.org&gt; >> >>>>> 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(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

- Main-Class is fine afaik. It was requested previously by users and added accordingly. I'm not going to change it unless you can show me concrete reason to. Seeing now that Version indeed defines a main() method, didn't expect

On Thu, Dec 28, 2017 at 11:58 AM Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > Automatic-Module-Name looks good. > > While unrelated, those look odd: > > * Main-Class: I don't think ORM - as a library - should declare this > * Specification-Title, Specification-Version: should these rather relate > to JPA title and version (as opposed to the Implementation-* ones)? > > > 2017-12-28 16:06 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >> After tweaking this, here is what I have... >> >> Manifest-Version: 1.0 >> Created-By: 1.8.0_121 (Oracle Corporation) >> Main-Class: org.hibernate.Version >> >> Specification-Title: hibernate-core >> Specification-Version: 5.3 >> Specification-Vendor: Hibernate.org >> >> Implementation-Title: hibernate-core >> Implementation-Version: 5.3.0.SNAPSHOT >> Implementation-Vendor-Id: org.hibernate >> Implementation-Vendor: Hibernate.org >> Implementation-Url: http://hibernate.org >> >> Automatic-Module-Name: org.hibernate.orm.core >> >> Bundle-ManifestVersion: 2 >> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))" >> Tool: Bnd-3.4.0.201707252008 >> >> Bundle-SymbolicName: org.hibernate.orm.core >> Bundle-Version: 5.3.0.SNAPSHOT >> Bundle-Name: hibernate-core >> Bundle-Description: A module of the Hibernate O/RM project >> Bundle-Vendor: Hibernate.org >> Bundle-DocURL: http://www.hibernate.org/orm/5.3 >> Bnd-LastModified: 1513615321000 >> >> Import-Package: ... >> Export-Package: ... >> >> >> Which looks great to me... >> >> On Wed, Dec 27, 2017 at 3:39 PM Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >> > I had intended this for 5.3 which hasn't even gone Beta yet (we wont >> have >> > an Alpha). >> > >> > On Wed, Dec 27, 2017 at 3:38 PM Brett Meyer <brett(a)hibernate.org&gt; >> wrote: >> > >> >> +1 from me on making them consistent. In practice, >> Bundle-SymbolicName >> >> isn't used for much, other than a guaranteed unique identifier. One >> of >> >> the Karaf guys pointed out that Bundle-SymbolicName is used to link a >> >> fragment bundle to its host bundle, but we've been able to avoid >> >> fragments like the plague on purpose. >> >> >> >> In practice, most users should be pulling in and interacting with our >> >> bundles purely through Maven artifacts or our features.xml, so a >> change >> >> would largely be unnoticed. >> >> >> >> We still might consider holding off doing that until at least a minor >> >> version change, since there is a potential issue for any tooling that >> >> might be relying on that (logging/auditing, etc.)... >> >> >> >> >> >> On 12/23/17 11:38 PM, Steve Ebersole wrote: >> >> > 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 <steve(a)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 < >> gunnar(a)hibernate.org&gt; >> >> >> wrote: >> >> >> >> >> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> >> >>> >> >> >>>> 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 < >> steve(a)hibernate.org&gt; >> >> >>>> wrote: >> >> >>>> >> >> >>>>> Thanks for investigating this Gunnar. >> >> >>>>> >> >> >>>>> Some thoughts inline... >> >> >>>>> >> >> >>>>> On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling < >> >> gunnar(a)hibernate.org&gt; >> >> >>>>> 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(a)lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> >> >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >

* 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

On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > * 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 > Actually this is different than what Sanne brought up. I actually cannot reproduce what Sanne is reporting. If I had to guess he was not specifying the bytecode provider to use "globally". This is a special kind of setting (we used to have a few) that can only be specified per-VM : either as a root `hibernate.properties` or as a System property. It has to do with how Hibernate builds its mapping model, specifically `org.hibernate.mapping.Component`. Given the redesign of the bootstrap process we may actually be able to remove that "VM wide" requirement. I'll look into that for 5.3. BTW Sanne, I created a repo[1] showing that this does indeed work when specified "properly".

[1] https://github.com/sebersole/orm-bytebuddy-no-javassist

2017-12-29 21:34 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> >> * 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 >> > > Actually this is different than what Sanne brought up. I actually cannot > reproduce what Sanne is reporting. If I had to guess he was not specifying > the bytecode provider to use "globally". This is a special kind of setting > (we used to have a few) that can only be specified per-VM : either as a > root `hibernate.properties` or as a System property. It has to do with how > Hibernate builds its mapping model, specifically > `org.hibernate.mapping.Component`. Given the redesign of the bootstrap > process we may actually be able to remove that "VM wide" requirement. I'll > look into that for 5.3. BTW Sanne, I created a repo[1] showing that this > does indeed work when specified "properly". > > Gunnar, what you are seeing is very different and I'm not sure of a way > to solve that yet. That is all part of auto-discovery of resources > (entities, embeddables, converters, etc) during bootstrap. We need to > inspect the file without loading the Class to look at its annotations. We > need *something* to do that, whether that is Jandex, Javassist, etc. Byte > Buddy may or may not have a similar facility. The problem here is that the > Javassist dependency is needed for a very different purpose. And without a > viable alternative solution, its going to have to stay that way. > Yes, understood it's for a different purpose. I don't think ByteBuddy itself will help with this task, but IIUC, ASM could be used to do so. ButeBuddy depends on ASM, there's one caveat, though, ASM isn't pulled in as a (transitive) dependency, but instead shaded into the ByteBuddy JAR. See the discussion at the bottom of http://bytebuddy.net/ (section "dependency maintenance") for details, it seems they recommend to shade ASM yourself to avoid any version conflicts. Not sure really what's the best here, might not be worth the hazzle and perhaps easiest just to live with the situation until this code has been migrated to Jandex. > [1] https://github.com/sebersole/orm-bytebuddy-no-javassist >