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

[Steve Ebersole]

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