java.net.URL and java.net.URLConnection need to be examined to see how they will work with modules.

The required protocol handlers are in the base module and should not be an issue. Now consider the case where non-standard protocol handlers (ftp, mailto, ...) are in a different module. Also consider the case of ContentHandler implementations in other modules, say sun.net.www.content.audio and sun.net.www.content.image in the desktop module.

This issue also needs to consider the case where the system property java.protocol.handler.pkgs is set and specifies packages in named modules that are exported. As these named modules are not readable to the base module then the types in these packages will not be accessible. The some straight-forward solution may be to just drop the legacy mechanism and replace it by the use of ServiceLoader to locate URLStreamHandlerFactory implementations. The only issue will be core protocols that are needed early in the startup or are needed to search the module path or class path for provider implementations. More likely this means that some core protocols will need to be specified as not being replaceable by this mechanism (file and jar for example). The only issue then might be deploy as they override the jar protocol handler and a solution will be needed to allow them do this after the module system initialization has completed.