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

[Sanne Grinovero]

On 3 February 2016 at 14:55, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> Sanne, proxies generated by Hibernate do depend on the Javassist code at
> runtime. So a lazy object would CNFE if Javassist was not in the
> classpath.

I get that. But *which classpath* matters.

Classes are owned by a specific classloader, and the instrumented code
can depend on javassist w/o this requiring the whole of the user
code's classloader to include javassist.

So I'm not saying that I definitely know how to solve it, but I think
it should be possible.. details matter and I don't have them.

For the record, people should be able to use JPA in WildFly without
being able to see any org.hibernate class too.

Sanne

>
> On Wed 2016-02-03 14:02, Sanne Grinovero wrote:
>> Hi Scott,
>> I'm missing something here: I think there is a 3rd option which is to
>> not require the user's classpath to "see" the Javassist at all, even
>> though Hibernate uses it.
>>
>> But I've said this before in other context, and yet we're back at
>> discussing only options 1 and 2, so I'm guessing that we either didn't
>> understand each other, or I'm missing some complexity in the use case
>> (I haven't seen the code!).
>>
>> To make progress I think I could try to help out with a proposal, but
>> I can only do that if you could share a unit test. What do you think
>> of that?
>> Of course there's the possibility that I'd give you a solution which
>> is valid only in the specific use case of that single test, but at
>> least it might clarify to you what I have in mind..
>>
>> an example worth more than a 1000 emails :)
>>
>> Thanks!
>> Sanne
>>
>> On 3 February 2016 at 13:53, 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
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev