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

[Stuart Douglas]

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> 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> 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
>>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160212/e4b4c044/attachment.html