Re: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules
Thanks for investigating this Gunnar.
Some thoughts inline...
On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling <gunnar(a)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
- ...