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

[Steve Ebersole]

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