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

[Steve Ebersole]

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.

On Wed, Feb 3, 2016 at 7:58 AM Steve Ebersole <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> 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
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>