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

[Scott Marlow]

It will be interesting to see what happens when we run the WildFly 
testsuite with your branch.  Thanks for jumping in Gunnar on helping! :-)

On 02/18/2016 06:35 AM, Gunnar Morling wrote:
> My branch at https://github.com/gunnarmorling/hibernate-orm/tree/HHH-10536
> is exactly doing this (using ByteBuddy).
>
> Generated proxy types invoke java.lang.reflect.InvocationHandler, i.e.
> no dependency to any library. Of course the same could be done either
> using ASM directly or ripping ProxyFactory out of Javassist and adapt
> it to do the same.
>
> --Gunnar
>
>
> 2016-02-18 12:11 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> It seems we're discussing this issue in multiple places,
>> so to let you all know I'll repeat it hare:
>> I think shading is a really really bad idea :)
>>
>> Could we try to have the enhanced entities to not need Javassist in in
>> their *direct* classloader; we can still have a normal Javassist as a
>> module dependency of Hibernate?
>> That would require to just make sure the generated bytecode doesn't
>> directly refer to Javassist types but uses an indirection controlled
>> by Hibernate code.. which in turn can use Javassist or even
>> alternatives in future, if we'd like to experiment.
>>
>> I'm not familiar enough with Javassist to know if that's an option
>> as-is but we can either improve Javassist to allow such a thing or use
>> some alternatives, like Gunnar and Hardy also suggested on the
>> hibernate-dev mailing list.
>>
>> To summarize, I agree with Stuart and would hope that Scott's branch
>> can be improved by minimizing the amount of Javassist code which
>> actually needs to be copied by using some simple delegation to
>> Hibernte types, which in turn can use a private, non-shaded Javassist
>> taking advantage of the isolation provided by JBoss Modules.
>>
>> --Sanne
>>
>>
>>
>> On 12 February 2016 at 03:19, Scott Marlow <smarlow at redhat.com> wrote:
>>> 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
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev