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

[Gunnar Morling]

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