Re: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules

+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