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

[Steve Ebersole]

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