[hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications...
steve at hibernate.org
Wed Feb 3 09:01:25 EST 2016
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
> 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?
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
More information about the hibernate-dev