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