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

[Scott Marlow]

On 02/03/2016 10:09 AM, Sanne Grinovero wrote:
> 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.

The user application code, does need javassist.  Look at 
https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e which is an 
example of user code needing 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.

I think that I responded to your previous comments on my WildFly pull 
request being wrong, since I exported the Javassist classes with 
Hibernate ORM (so that Hibernate native applications would not get a 
CNFE).  I suspect that the details are too long to read or perhaps I was 
not clear on that thread.  But, my pull request was pretty much shot 
down so far because Hibernate applications should not be required to 
have Javassist on the application classpath, as that could conflict with 
applications that want their own copy of Javassist.

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

Are you saying that only JPA applications that contain a reference to a 
org.hibernate class should have the Hibernate classes on the application 
classpath?  Or that the Hibernate runtime should not ever expect to find 
Hibernate classes on the application classpath?

>
> 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