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

[Scott Marlow]

On 02/03/2016 10:11 AM, Scott Marlow wrote:
>
> On 02/03/2016 09:01 AM, Steve Ebersole wrote:
>> I should point out... The big drawback with that (and with cloning in
>> general since its the Javassist package renaming that is important in
>> both) is that its no longer a simple matter update (bug-fixes, etc)
>> Javassist usage in Hibernate.  Its certainly no longer simple as in
>> drop-in the replacement from upstream.
>
> True, many users like to workaround Javassist issues by dropping a
> different Javassist version in.

My vote is to change Hibernate to include its own Hibernate-Javassist 
(shaded or whatever repackaging tricks are needed) jar.

Some recent cases that I have heard of users needing to use a different 
version of Javassist with Hibernate were:

A. On certain application servers that included an older Javassist jar 
that an upgraded Hibernate ORM release was not compatible with the older 
Javassist jar.  With a shaded Hibernate-javassist jar, we wouldn't have 
any conflicts between the Hibernate use of Javassist and the 
javassist.jar file (since users would have a separate global 
hibernate-javassist jar).

B.  Users needing to use some later release of Javassist to address a 
bug that they experienced with Hibernate's use of Javassist.  I think 
that these users will need to upgrade to a later version of Hibernate to 
use the newer Javassist.

Scott

>
>>
>> On Wed, Feb 3, 2016 at 7:58 AM Steve Ebersole <steve at hibernate.org
>> <mailto:steve at hibernate.org>> wrote:
>>
>>      Just as a suggestion, we do not need to go to a "full on" clone for
>>      your (1).  A fat-jar, shaded-jar, <your favorite plugin here> should
>>      also do the trick.
>>
>>
>>      On Wed, Feb 3, 2016 at 7:54 AM Scott Marlow <smarlow at redhat.com
>>      <mailto:smarlow at redhat.com>> wrote:
>>
>>          As modular classloading environments become more popular (e.g.
>>          WildFly,
>>          OSGi, Openjdk Jigsaw), it is more important that applications can
>>          include their own version of Javassist classes.  This is not
>>          possible if
>>          the application classpath also needs to include the Hibernate
>>          (needed)
>>          version of Javassist.
>>
>>          My question is how would/should this be accomplished?  Some
>>          proposals
>>          are below:
>>
>>          1.  Clone the Javassist runtime classes into Hibernate ORM and
>>          maintain
>>          them as a fork.  I don't think this is practical but still wanted to
>>          mention it as a possible solution.
>>
>>          2.  Stop using the parts of the Javassist api that generate bytecode
>>          that depends on the Javassist runtime classes.  I have no idea
>>          how hard
>>          this would be.
>>
>>          I don't think we have a jira for this yet, although we have
>>          talked about
>>          it occasionally for years.
>>
>>          Any volunteers to help?
>>
>>          Scott
>>          _______________________________________________
>>          hibernate-dev mailing list
>>          hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>>          https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>