RFR JDK-8044627: Update JNDI to work with modules

[Pavel Rappo]

Daniel,

> So is it expected that modules (e.g. java.corba) will register
> their own service provider for the InitialContextFactory
> (I mean - using META-INF/services/)?

Alan's already answered this point. TCCL is the way to go. You are right.

> The difference however is that in  this two case we're looking for
> a service implementing a specific feature, we're not looking for a
> service whose concrete class matches a specific class name.

Agreed.

> In the case of InitialContextFactory - as a client of the API, I
> would be a bit surprised if - asking for a LDAP InitialContext,
> I received a CORBA exception. This would look strange to me.

Once again, agreed.

> A possibilty might be to use InitialContextFactoryBuilder as the
> service interface instead, and loop over the implementations until
> you find one that does not throw NamingException - but then it
> would be difficult to make the distinction between
> 'This builder does not support the Context.INITIAL_CONTEXT_FACTORY
> that you ask for' and 'The InitialContextFactory could not be
> instantiated for various reasons'...

The closest thing to what you described here would be java.sql.DriverManager:664, I think. I don't think this is an acceptable for JNDI though. This would require to modify all the providers out there to provide a new entry point -- their own implementation of InitialContextFactoryBuilder.

> Maybe it's because I haven't used JNDI very often, but when
> I read the spec I didn't realize that the value of Context.INITIAL_CONTEXT_FACTORY would have any effect if
> ServiceLoader was used - because it's not usual to use
> ServiceLoader in this way (even though the usage of
> ServiceLoader is nested below 'the class specified in
> the Context.INITIAL_CONTEXT_FACTORY</tt> environment property
> is used').
> I'm not sure it would be overspecifying to say that the ServiceLoader
> is used to locate and load an implementation of the service whose
> concrete class matches the named class - since that's what it's
> doing anyway - but I understand your concern.

It's definitely worth thinking about. Thanks.

> So a broken InitialContextFactory for technology XXX can
> prevent getting the InitialContext for technology YYY even if both
> have nothing in common, and even if XXX is never actually
> used in the application.

+1 It indeed seems very strange at first sight. But I believe this thing is a subjective tradeoff between the effects caused by unexpected "CORBA exception" and the effects caused by some strange behaviour after an "unrelated" exception was silently swallowed by the runtime.
It's more like a fail-fast behaviour, when even "unrelated" things are reported about:

	I dropped by your house to deliver the letter. Btw, it seems you've left you kettle on...

Some time ago I asked myself the same question. And looked through the codebase to see how the ServiceLoader is used. I found some "fault-tolerant" implementations:

	com.sun.media.sound.JSSecurityManager:189
	java.sql.DriverManager:605
	sun.tools.jconsole.JConsole:1004
	com.sun.tools.attach.spi.AttachProvider:261
	com.sun.tools.jdi.VirtualMachineManagerImpl:95
	com.sun.tools.jdi.VirtualMachineManagerImpl:124
	javax.script.ScriptEngineManager:124

As you can see there's no right answer here. It certainly depends on the behaviour you want to achieve. Suppose your service provider are plugins (as it is the case for JConsole example above) then it doesn't make any sense to shutdown if any single plugin failed. Leave this decision to a client. Report the warning. On the language level there's no such thing is warning. Only exceptions and return values. We could emulate warning with logging but... I'm sure there are many reasons why that might not fly.
 
-Pavel