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

[Gunnar Morling]

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