RFR JDK-8044627: Update JNDI to work with modules

Alan Bateman Alan.Bateman at oracle.com
Tue Sep 16 14:56:50 UTC 2014

On 16/09/2014 15:14, Pavel Rappo wrote:
> Daniel,
>> Given that helper.loadClass uses the context class loader,
>> Should you also simply use
>>   ServiceLoader<InitialContextFactory> loader =
>>                      ServiceLoader.load(InitialContextFactory.class);
>> at lines 680-681 ?
> It needs to be the system class loader to allow for JNDI providers that might be on the class path or module path.
The TCCL would be more appropriate here as that would allow for JNDI 
providers that are bundled with the application (the TCCL should 
eventually delegate to the system class loader so it should find the 
JNDI provider on the class path or linked into the runtime image too).

> :
> IMO, it's not just an inconvenience, but rather a part of ServiceLoader's design. I mean, it's definitely designed to provide, so to say, a "one-to-many" mapping for the classes (providers) that implements some interface (a service) to a client. It merely delivers you implementations. You should than iterate though them and decide which one satisfies your needs. I'm not sure it's a good idea to get services based on their implementation classnames.
Right, it's the user of ServiceLoader that does the selection. The real 
issue here of course is the JNDI API where the user specifies the class 
name of the implementation factory when creating the initial context. 
I've no doubt that it would be done differently if re-designed now.


More information about the core-libs-dev mailing list