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
