RFR: 8223260: NamingManager should cache InitialContextFactory

Peter Levart peter.levart at gmail.com
Wed Feb 5 15:31:16 UTC 2020

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

More information about the core-libs-dev mailing list