[wildfly-dev] private packaging Javassist jar in Hibernate ORM, so applications can have their own Javassist jar...

[Scott Marlow]

What if Javassist packaged these same (proxy/runtime) classes in a 
separate javassist-runtime jar and we shaded only the proxy/runtime 
classes?  That way we only repackage the same classes that we included 
for this hack test (e.g. 
org.hibernate.bytecode.internal.javassist.proxy.*).

Early testing results of the hack test look good 
(https://gist.github.com/scottmarlow/ad878968c5a7c6fbbfb7).

Scott

On 02/11/2016 09:04 PM, Stuart Douglas wrote:
> It depends if you are going to shade all the javassist classes or just
> the "javassist.util.proxy" package (not sure if this is actually
> possible with the shade plugin).
>
> The main advantage is that you can upgrade javassist to get fixes to
> issues that affect bytecode generation. So if JDK9 comes out with new
> bytecodes that the current version of Javassist does not understand then
> upgrading javassist will allow the older version of hibernate to work
> with classes compiled against the newer JDK version. If all of javassist
> is shaded into hibernate then that version of hibernate will never work
> with the newer bytecodes.
>
> I think this is less of an issue if you are still publishing the
> non-Javassist shaded hibernate as well as a shaded version, but if the
> only published artifact has javassist shaded in then it may limit
> forward compatibility.
>
> Stuart
>
>
> On Fri, 12 Feb 2016 at 12:53 Steve Ebersole <steve at hibernate.org
> <mailto:steve at hibernate.org>> wrote:
>
>     Ugh.  That is an awful lot of classes copied over.  What exactly was
>     the benefit of this over shading again?  I mean both case lose the
>     ability to simply drop in fixes from upstream Javassist.  So what
>     does this "clone" approach gain versus shadowing?
>
>
>
>     On Thu, Feb 11, 2016 at 7:13 PM Scott Marlow <smarlow at redhat.com
>     <mailto:smarlow at redhat.com>> wrote:
>
>          >>
>          >>      On 02/11/2016 03:02 PM, Stuart Douglas wrote:
>          >>       > Have you considered a 3rd alternative, which is to
>         use a custom
>          >>       > ProxyFactory instead of javassists built in one?
>          >>       >
>          >>       > AFAIK the main issue is that javassist proxies
>         require access to the
>          >>       > 'javassist.util.proxy.MethodHandler|RuntimeSupport'
>         classes. You
>          >>      could
>          >>       > create a similar org.hibernate interface, and a
>         proxy factory
>          >>      that uses
>          >>       > this method handler instead.
>          >>       >
>          >>       > Basically you just copy the code from
>         javassist.util.proxy into
>          >>       > hibernate. This is a relatively small amount of
>         code, so it
>          >>      should not
>          >>       > really add any maintenance burden.
>          >>
>          >>      We talked about this as well via [1].  I understand the
>         concept but have
>          >>      not tried doing this.  I like this approach as well, if
>         it works.  One
>          >>      of the cons with cloning that Steve Ebersole pointed
>         out (see response
>          >>      on Feb-03-2016 9:01am), is that that users lose the
>         ability to drop a
>          >>      different version of Javassist in (since we maintain
>         our own cloned copy
>          >>      of the Javassist proxy/runtime code).
>          >>
>          >>
>          >> The proxy code is a relatively small part of javassist, so
>         unless a bug
>          >> is in the proxy code itself this should not be that big a deal.
>          >
>          > Thanks for the encouragement to go down this path.  :)
>          >
>
>         Started a hack attempt at the clone via
>         https://github.com/scottmarlow/hibernate-orm/tree/javassistproxy.
>         Seems
>         to pass the Hibernate ORM unit tests.
>
>         Scott
>
>         _______________________________________________
>         wildfly-dev mailing list
>         wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>
>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>