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

[Steve Ebersole]

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..



> * 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.



> * 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?


* 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


* 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?



> 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?

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
   - ...