+1 Avoiding a runtime dependency seems far better than shading. Maybe the same could be done with Javassist?
On Wed, 17 Feb 2016 12:15 Gunnar Morling <gun...@hibernate.org> wrote: > Hi, > > I'd like to propose an alternative approach for proxy generation which > would avoid version issues with Javassist. > > The idea is to generate proxies which are fully "self-contained", i.e. > their byte code contains no references to a library such as Javassist, > but instead invocations of a either a custom method handler contract > we define ourselves or something unproblematic such as > java.lang.reflect.InvocationHandler. > > Such code generation could be done "by hand" using ASM, but there is a > handy library named ByteBuddy [1] which essentially provides a nice > DSL for creating types at runtime (it sits on top of ASM itself). It > makes it very easy to create proxy classes which call out to an > instance of InvocationHandler when the proxied methods are called. > Note that it enables the usage of InvocationHandler not only for > interfaces (such as the original usage in the JDK) but also for class > proxies. > > The code generated for proxies does not contain any references to > ButeBuddy's API, i.e. after creation they are usable without ByteBuddy > being available (*). That way ByteBuddy should not have to be exposed > to user deployments, unlike with the current Javassist solution. It'd > only be a tool used *internally* within Hibernate. > > I've pushed a very rough draft of that approach to my fork of ORM at > > https://github.com/hibernate/hibernate-orm/commit/0b1739059b74aaab7d3aa91bba85b204ee367d92 > . > > It's not complete and some tests fail. I'd need to look into these in > more depth, but I don't think they represent general problems. But > this sketch might be good enough already to be dropped into WildFly > and run some tests. > > Any feedback welcome. > > Cheers, > > --Gunnar > > [1] bytebuddy.net/ > (*) I could serialize a generated proxy to disk and re-read+execute it > subsequently from another application without ByteBuddy on the > classpath > > > 2016-02-16 20:07 GMT+01:00 Scott Marlow <smar...@redhat.com>: > > https://hibernate.atlassian.net/browse/HHH-10536 is for tracking this. > > Please revise as it makes sense. > > > > In the related WildFly dev discussion about $subject, Stuart asked if we > > would have two separate Hibernate ORM jars (one that depends on the > > shaded Javassist and one that depends on regular Javassist). That seems > > like a separate concern but perhaps others will feel stronger about it. > > > > Also, in the WildFly discussion, I asked whether it makes a difference > > to Hibernate, whether the javassist.util.proxy classes that we want to > > shade, are in the javassist.jar or a new javassist-runtime.jar? If we > > shade all of the classes in a javassist-runtime.jar, that might be a > > better long term contract, then if we shaded the javassist.util.proxy > > classes which could be renamed over time. Does it make a difference > > whether we shade the javassist.util.proxy or entire > javassist-runtime.jar? > > > > Thanks, > > Scott > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
