[hibernate-dev] Using Hibernate ORM as automatic JPMS modules
Brett Meyer
brett at hibernate.org
Fri Dec 29 11:45:37 EST 2017
Sorry folks, responding to this thread out of order...
Steve, at first glance, this looks fine!
On 12/28/17 10:06 AM, Steve Ebersole 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 <http://osgi.ee>;filter:="(&(osgi.ee
> <http://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
> <mailto: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
> <mailto: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 <mailto: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 <mailto:gunnar at hibernate.org>>
> >> wrote:
> >>
> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole
> <steve at hibernate.org <mailto: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 <mailto: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 <mailto: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
> <mailto:hibernate-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> <mailto:hibernate-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
More information about the hibernate-dev
mailing list