Of course I meant "continuing with Javassist..." :P On Tue, Jan 2, 2018 at 3:50 PM Steve Ebersole <st...@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 <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
