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.
-Alan
More information about the core-libs-dev
mailing list