On 2/5/20 2:46 PM, Alan Bateman wrote:
On 05/02/2020 11:53, Peter Levart wrote:
:
Please, include me in the conversation. I would like to know whether
this is really possible, because I think it is not. If the
implementation class / provider type is resolved using thread's
context class loader, then it is the responsibility of the service
implementation to only reference such objects that are backed by
classes that are also resolvable by the same class loader. If service
implementation does not respect that, then class loader leaks are
inevitable even if you don't cache the service implementation
instance (in your case the InitialContextFactory). So I think there's
no point in wrapping the InitialContextFactory with SoftReference.
You only complicate things as you would have to account for
situations where the SoftReference is cleared...
Anybody has a different view?
I think this is about allow the InitialContextFactory instance to be
GC'ed when the thread is long lived. It might not be a concern for the
LDAP or the other providers in the JDK.
-Alan
Ah, I see. You mean when the ClassLoader is long lived. So this is a
normal matter of trying to release the InitialContextFactory and objects
held by it when there is a memory pressure and not the matter of
avoiding class loader leaks? In this case it would pay only if
InitialContextFactory holds more memory than SoftReference itself...
Regards, Peter
