[hibernate-dev] How best to eliminate the Javassist dependency from Hibernate applications...
Vlad Mihalcea
mihalcea.vlad at gmail.com
Wed Feb 3 10:08:26 EST 2016
Hi,
If the user has used bytecode enhancement, the generated transformed entity
classes depend on Javassist too,
and that's even more complicated because it requires the client to
regenerate those classes if we drop support for Javassist.
Vlad
On Wed, Feb 3, 2016 at 4:55 PM, 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.
>
> 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
More information about the hibernate-dev
mailing list