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

Steve Ebersole steve at hibernate.org
Thu Dec 28 13:10:35 EST 2017 

   - 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.
   - Specification-* - I had considered that.  TBH its not important
   afaik.  And Hibernate defines a specification as well (its API) that is a
   super set of JPA.  And its not like I just added this.  Those have been
   generated into the manifest at least as far back as the move to Gradle.
   I've yet to hear a compliant besides yours today


On Thu, Dec 28, 2017 at 11:58 AM Gunnar Morling <gunnar at hibernate.org>
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 at hibernate.org>:
>
>> 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 at 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 at 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 at 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 at hibernate.org>
>> >> >> wrote:
>> >> >>
>> >> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole <steve at 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 at hibernate.org>
>> >> >>>> wrote:
>> >> >>>>
>> >> >>>>> Thanks for investigating this Gunnar.
>> >> >>>>>
>> >> >>>>> Some thoughts inline...
>> >> >>>>>
>> >> >>>>> On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling <
>> >> gunnar at 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 at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> >>
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

More information about the hibernate-dev mailing list