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

[Steve Ebersole]

Of course I meant "continuing with Javassist..." :P

On Tue, Jan 2, 2018 at 3:50 PM Steve Ebersole <steve at hibernate.org> wrote:

> ASM is a completely different model though, unless the part you think
> could be used here is different.
>
> I did say though that we could leverage Jandex for this part.  The problem
> (iiuc) there though is that Jandex would require all classes to be indexed
> - we could not just ask it to index a particular file and then get that
> "class descriptor" from the IndexView.
>
> So I agree, unless there is a better option someone proposes (and honestly
> is willing to work on), I think continuing with Jandex for the scanning
> piece is going to be the route we go for 5.3
>
> On Tue, Jan 2, 2018 at 3:23 PM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> 2017-12-29 21:34 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>>
>>>> * 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
>>>>
>>>
>>> Actually this is different than what Sanne brought up.  I actually
>>> cannot reproduce what Sanne is reporting.  If I had to guess he was not
>>> specifying the bytecode provider to use "globally".  This is a special kind
>>> of setting (we used to have a few) that can only be specified per-VM :
>>> either as a root `hibernate.properties` or as a System property.  It has to
>>> do with how Hibernate builds its mapping model, specifically
>>> `org.hibernate.mapping.Component`.  Given the redesign of the bootstrap
>>> process we may actually be able to remove that "VM wide" requirement.  I'll
>>> look into that for 5.3.  BTW Sanne, I created a repo[1] showing that this
>>> does indeed work when specified "properly".
>>>
>>> Gunnar, what you are seeing is very different and I'm not sure of a way
>>> to solve that yet.  That is all part of auto-discovery of resources
>>> (entities, embeddables, converters, etc) during bootstrap.  We need to
>>> inspect the file without loading the Class to look at its annotations.  We
>>> need *something* to do that, whether that is Jandex, Javassist, etc.  Byte
>>> Buddy may or may not have a similar facility.  The problem here is that the
>>> Javassist dependency is needed for a very different purpose.  And without a
>>> viable alternative solution, its going to have to stay that way.
>>>
>>
>> Yes, understood it's for a different purpose. I don't think ByteBuddy
>> itself will help with this task, but IIUC, ASM could be used to do so.
>> ButeBuddy depends on ASM, there's one caveat, though, ASM isn't pulled in
>> as a (transitive) dependency, but instead shaded into the ByteBuddy JAR.
>> See the discussion at the bottom of http://bytebuddy.net/ (section
>> "dependency maintenance") for details, it seems they recommend to shade ASM
>> yourself to avoid any version conflicts.
>>
>> Not sure really what's the best here, might not be worth the hazzle and
>> perhaps easiest just to live with the situation until this code has been
>> migrated to Jandex.
>>
>>
>>> [1] https://github.com/sebersole/orm-bytebuddy-no-javassist
>>>
>>
>>