Use the "temp classloader" model to always build hibernate-models

Description

Currently, Hibernate does extra work to ensure that user domain classes are not loaded into the “system classloader” during bootstrap to allow for potentally enhancing those classes.

In JPA EE environments we are given a potential way to handle this via JPA’s PersistenceUnitInfo#getNewTempClassLoader. However, Hibernate has never really leveraged that solution. Instead we use (historically) HCANN or hibernate-models (with Jandex) to help with this. And I even started on a new hibernte-models module to allow using Byte Buddy instead of Jandex. So some complexity there trying to make sure those things all do the same relative output for the same inputs

To alleviate that specific complexity, I have been thinking about JPA’s approach of using a temp classloader. In EE environments, we are already guarenteed to be passed an appropriate one by the container. But in other environments, we could just as easily create our own throw-away ClassLoader.

We’d need the ability to “migrate” classes we loaded into our thro-away loader into the “system classloader” at some point (late) during the bootstrap process. An API for that is relatively straight-forward -

interface ClassDetails { ... <J> Class<J> toJavaClass(ClassLoading classLoading, SourceModelContext context); } interface MemberDetails { ... Member toJavaMember(Class declaringClass, SourceModelContext context); } interface FieldDetails extends MemberDetails { ... @Override Method toJavaMember(Class declaringClass, SourceModelContext context); } ...

Of course, the throw-away classloader should always use the form in the parent classloader if the Class is already loaded there. Otherwise, wed load and resolve it into the throw-away classloader.

Activity

Show:
Steve Ebersole
updated the Description4 days ago
Currently, Hibernate does extra work to ensure that user domain classes are not loaded into the “system classloader” during bootstrap to allow for potentally enhancing those classes. In JPA EE environments we are given a potential way to handle this via JPA’s {{PersistenceUnitInfo#getNewTempClassLoader}}. However, Hibernate has never really leveraged that solution. Instead we use (historically) HCANN or hibernate-models (with Jandex) to help with this. And I even started on a new hibernte-models module to allow using Byte Buddy instead of Jandex. So some complexity there trying to make sure those things all do the same relative output for the same inputs To alleviate that specific complexity, I have been thinking about JPA’s approach of using a temp classloader. In EE environments, we are already guarenteed to be passed an appropriate one by the container. But in other environments, we could just as easily create our own throw-away ClassLoader. We’d need the ability to “migrate” classes we loaded into our thro-away loader into the “system classloader” at some point (late) during the bootstrap process. An API for that is relatively straight-forward - {code:java}interface ClassDetails { ... <J> Class<J> toJavaClass(ClassLoading classLoading, SourceModelContext context); } interface MemberDetails { ... Member toJavaMember(Class declaringClass, SourceModelContext context); } interface FieldDetails extends MemberDetails { ... @Override Method toJavaMember(Class declaringClass, SourceModelContext context); } ...{code}
Currently, Hibernate does extra work to ensure that user domain classes are not loaded into the “system classloader” during bootstrap to allow for potentally enhancing those classes. In JPA EE environments we are given a potential way to handle this via JPA’s {{PersistenceUnitInfo#getNewTempClassLoader}}. However, Hibernate has never really leveraged that solution. Instead we use (historically) HCANN or hibernate-models (with Jandex) to help with this. And I even started on a new hibernte-models module to allow using Byte Buddy instead of Jandex. So some complexity there trying to make sure those things all do the same relative output for the same inputs To alleviate that specific complexity, I have been thinking about JPA’s approach of using a temp classloader. In EE environments, we are already guarenteed to be passed an appropriate one by the container. But in other environments, we could just as easily create our own throw-away ClassLoader. We’d need the ability to “migrate” classes we loaded into our thro-away loader into the “system classloader” at some point (late) during the bootstrap process. An API for that is relatively straight-forward - {code:java}interface ClassDetails { ... <J> Class<J> toJavaClass(ClassLoading classLoading, SourceModelContext context); } interface MemberDetails { ... Member toJavaMember(Class declaringClass, SourceModelContext context); } interface FieldDetails extends MemberDetails { ... @Override Method toJavaMember(Class declaringClass, SourceModelContext context); } ...{code} Of course, the throw-away classloader should always use the form in the parent classloader _if_ the Class is already loaded there. Otherwise, wed load and resolve it into the throw-away classloader.
Steve Ebersole
created the Issue4 days ago

Details

Assignee

Reporter

Priority

Created 4 days ago
Updated 4 days ago