[hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications...

[Sanne Grinovero]

+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 <gunnar at 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 <smarlow at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>