[jpa-spec users] contract change for PersistenceUnitInfo#getNewTempClassLoader() call...

From: Scott Marlow <>
Date: Tue, 25 Oct 2016 13:54:01 -0400


Do persistence providers really need the
PersistenceUnitInfo#getNewTempClassLoader() call [1] to always return
a new ClassLoader instance? I propose to simplify the
getNewTempClassLoader() requirements by instead allowing the returned
temporary class loader to be cached at the persistence unit level
(until the PersistenceProvider.createContainerEntityManagerFactory()
call returns).

To express this change in a future JPA release, the Javadoc wording
could be changed to:

ClassLoader getNewTempClassLoader()

Return a new instance of a ClassLoader that the provider may use to
temporarily load any classes, resources, or open URLs. The scope and
classpath of this loader is exactly the same as that of the loader
returned by getClassLoader(). None of the classes loaded by this class
loader will be visible to application components. The provider may
only use this ClassLoader within the scope of the
java.util.Map) call. Multiple calls to getNewTempClassLoader() may
return the same (temporary) classloader that is scoped to the
persistence unit.

Returns: temporary ClassLoader with same visibility as current loader

For the most part, I think that persistence providers are already only
calling getNewTempClassLoader() once per persistence unit, so this
change should be a logical no-op. The advantage of applying this
contract change, is that JPA containers could cache the temp
classloader to improve deployment with persistence providers that
might not already cache the getNewTempClassLoader() result.

If others agree, we can create a JPA spec jira to track the Javadoc
change request.