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

Wed Dec 27 16:39:55 EST 2017

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