RFR: 8223260: NamingManager should cache InitialContextFactory

[Peter Levart]

On 2/7/20 12:11 AM, Seán Coffey wrote:
>
> On 6 February 2020 21:13:52 GMT, Peter Levart <peter.levart at gmail.com> wrote:
>>
>> On 2/6/20 6:54 PM, Seán Coffey wrote:
>>> the current proposal is still:
>>> http://cr.openjdk.java.net/~coffeys/webrev.8223260.v2/webrev/
>> But wasn't this one already better:
>>
>> https://cr.openjdk.java.net/~coffeys/webrev.8223260.v3/webrev/
> D'oh! You're right Peter. v3 is my preference (and most up to date) at the moment. I'll look at Alan's comment in the morning. I could create a custom exception if the current UndeclaredThrowableException is not a good use.

Well, theoretically, some implementation of InitialContextFactory could, 
in its constructor, use a not well-behaved dynamic Proxy which could 
throw UndeclaredThrowableException with NoInitialContextException as a 
cause and such exception would get unwrapped later in 
NamingManager.getInitialContext() where it would mistakenly be 
identified as an exception constructed in NamingManager.getFactory 
method. Using your own sub-type of RuntimeException for tunneling the 
NoInitialContextException through the functional interface (lambda) 
would eliminate even this remote possibility. Perhaps a pubic but 
confined com.sun.naming.internal.RuntimeNamingException (modeled after 
RuntimeIOException) would be a good name and could be re-used for 
possible similar needs in the future. A private static nested class in 
NamingManager could do it too.

Regards, Peter

>
> Regards,
> Sean.
>
>> Or do you prefer the v2 so that spec change and behavior change would
>> be
>> synchronized?
>>
>>
>> Regards, Peter
>>
>>> I'd like to make the specification change in a follow on bug ID (if
>>> that works for people)
>>>
>>> Regards,
>>> Sean.
>>>
>>> On 06/02/20 17:49, Alan Bateman wrote:
>>>> On 06/02/2020 15:32, Seán Coffey wrote:
>>>>> InitialContextFactory itself is an extremely simple interface with
>>>>> one method. I've browsed some code bases and could only find a
>> small
>>>>> number of such Factories implementations with simple logic to
>> return
>>>>> a Context. Applications will most likely delegate to the same
>>>>> Factory over and over also (albeit, it's all controlled by
>> HashTable
>>>>> parameters). The new caching logic should help memory pressure here
>>>>> and not hinder it. I'm not seeing a major concern with current
>>>>> solution as a result.
>>>> Okay, although I could imagine a non-JDK InitialContextFactory
>>>> implementation keeping a graph of objects alive. I saw your mail
>>>> about separating the clarification in the APIs docs so does it mean
>>>> the proposal on the table is the last webrev or is there a new
>> version?
>>>> -Alan