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