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

Wed Dec 27 16:36:47 EST 2017

+1 from me on making them consistent.  In practice, Bundle-SymbolicName 
isn't used for much, other than a guaranteed unique identifier.  One of 
the Karaf guys pointed out that Bundle-SymbolicName is used to link a 
fragment bundle to its host bundle, but we've been able to avoid 
fragments like the plague on purpose.

In practice, most users should be pulling in and interacting with our 
bundles purely through Maven artifacts or our features.xml, so a change 
would largely be unnoticed.

We still might consider holding off doing that until at least a minor 
version change, since there is a potential issue for any tooling that 
might be relying on that (logging/auditing, etc.)...

On 12/23/17 11:38 PM, Steve Ebersole wrote:
> 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
>>>>>     - ...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev