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 <gun...@hibernate.org> wrote: > 2017-12-29 21:34 GMT+01:00 Steve Ebersole <st...@hibernate.org>: > >> On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole <st...@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 >> > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
