RFR: 8223260: NamingManager should cache InitialContextFactory

Seán Coffey sean.coffey at oracle.com
Fri Feb 7 14:25:17 UTC 2020


I've also created JDK-8238688 to track the specification clarification 
request. I'll start an RFR for that shortly.

Regards,
Sean.

On 07/02/20 14:23, Seán Coffey wrote:
> I've introduced such a class: FactoryInitializationError
>
> Also added a new simple testcase method check for case where this new 
> exception would be exercised : testBadContextCall(Hashtable)
>
> http://cr.openjdk.java.net/~coffeys/webrev.8223260.v4/webrev/ 
> <http://cr.openjdk.java.net/%7Ecoffeys/webrev.8223260.v4/webrev/>
>
> Regards,
> Sean.
>
> On 07/02/20 10:45, Alan Bateman wrote:
>>
>>
>> On 07/02/2020 10:36, Peter Levart wrote:
>>> :
>>>
>>> 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. 
>> The concern is more that UndeclaredThrowableException is specified 
>> for handling exceptions on proxy interfaces. The question in one of 
>> the replies was whether there is a more appropriate exception to 
>> carry the checked exception. A static nested exception class would be 
>> fine.
>>
>> -Alan
>



More information about the core-libs-dev mailing list