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

Steve Ebersole steve at hibernate.org
Fri Dec 29 10:58:13 EST 2017 

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 at 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/junit/org.hibernate.osgi.test/
>
>
>
> On Thu, Dec 28, 2017 at 9:06 AM Steve Ebersole <steve at 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;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
>>>
>>>

More information about the hibernate-dev mailing list