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

[Emmanuel Bernard]

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.

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