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

[Scott Marlow]

On 02/11/2016 05:40 PM, Stuart Douglas wrote:
>
>
> On Fri, 12 Feb 2016 at 07:41 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.  :)

>
> If they do go down the shade route will this shaded hibernate+javassist
> be a different artifact (i.e. will they still publish a non javassist
> version of hibernate)?

Good question, I'm not really sure.

>
> Stuart
>
>
>     If we use a private packaged copy of the jars, in order to use a
>     different version of Javassist, users would have to get a new version of
>     Hibernate that is built with that different Javassist (as you point
>     out).
>
>     I would like to create a HHH jira for this issue that doesn't require a
>     specific implementation technique, so we can track this issue.
>
>     Scott
>
>     [1]
>     http://lists.jboss.org/pipermail/hibernate-dev/2016-February/014219.html
>
>      >
>      > The inability to change javassist versions could be a major pain for
>      > Hibernate later on, as it may mean that older hibernate versions
>     fail to
>      > work with newer JDK's if changes are made to the class file format.
>      >
>      > Stuart
>      >
>      > On Fri, 12 Feb 2016 at 03:03 Scott Marlow <smarlow at redhat.com
>     <mailto:smarlow at redhat.com>
>      > <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>      >
>      >     As previously discussed, Hibernate applications need access
>     to the
>      >     Javassist runtime classes (see example [1] enhanced
>     application entity
>      >     if you didn't know this :).  A proposal was discussed on the
>      >     hibernate-dev mailing list that I think is the best short
>     term solution.
>      >        I wanted to raise this issue here also, as I would like to
>     later
>      >     create a pull request to bring in a new Hibernate ORM that
>     includes this
>      >     change.  So, getting early feedback before we create JIRAs
>     for the work,
>      >     is important.
>      >
>      >     The proposal is to private package (or shade), the Javassist
>     classes, so
>      >     that Hibernate ORM has its own copy of the Javassist classes.  On
>      >     WildFly, we still would include Javassist for the other
>     components that
>      >     use it and for Hibernate applications that have "build-time
>     enhanced
>      >     entity classes" by an earlier Hibernate release.
>      >
>      >     One downside of this change is that Hibernate applications
>     cannot easily
>      >     switch to a different version of the Javassist classes.
>      >
>      >     Another downside is that applications that depend on an older
>     Hibernate
>      >     ORM version that includes "build-time enhanced entity
>     classes", will
>      >     need to be cracked open, to add dependencies on the Javassist
>     module
>      >     (since we will stop automatically adding Javassist to JPA
>     application
>      >     deployments).
>      >
>      >     The advantage of this change, is that Hibernate applications
>     can include
>      >     their own version of Javassist.
>      >
>      >     This will also have an impact on Hibernate build-time
>     enhancing of
>      >     entity classes (e.g. enhanced bytecode will no longer depend
>     on the
>      >     public Javassist classes).
>      >
>      >     Scott
>      >
>      >     [1] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
>      >     _______________________________________________
>      >     wildfly-dev mailing list
>      > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     <mailto:wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org>>
>      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >
>