RFR: 8223260: NamingManager should cache InitialContextFactory

[Peter Levart]

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