Modularizing URLStreamHandlerFactory

[David Holmes]

On 16/06/2012 7:17 AM, Jesse Glick wrote:
> Something to consider - in a big application it is not uncommon to have
> multiple URL handlers implemented in various places. Yet the JRE only
> lets you set a single URLStreamHandlerFactory for the whole JVM. So for
> the application to be modular, you need to write a proxy factory which
> accepts modular registrations, but that impedes interoperability since
> you must define a proprietary interface for this.
>
> It would be nicer for a modular JRE to allow URL handler factories to be
> registered as services. OSGi and the NetBeans module system both do
> something like this.
>
> Similar arguments could perhaps be made for other pluggable singletons
> in the current Java platform API (UncaughtExceptionHandler, FileNameMap,

When we added UncaughtExceptionHandler we recognized the desirability to 
have a "per app" default rather than only having the global default, but 
there was/is no "application context" to define-in or extract-from the 
UEH. I don't see how a modular JRE has changed that at all? Even if you 
say the UEH is a service, what is the scope/context of that service?

Further, what additional class support do services drag into the 
runtime? Are these classes that are already in the base module?

David
-----


> ProxySelector, HostnameVerifier, SSLSocketFactory, ...) but
> URLStreamHandlerFactory is the one which I know matters.