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

Thu Dec 28 12:58:05 EST 2017

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
>