Ugly things done to support multiple ContentHandlerFactory and URLStreamHandlerFactory

[Chris Hegarty]

Hi Tom,

We are aware of some of these issues, but I have to admit that I still
don't have a good handle on all the use-cases. One of the more straight
forward is the "wrapping" of the built-in handlers, for the case where
the framework does not want to re-implement all the existing JDK
supported protocols when it wants to add, or intercept, on a small set,
or even delegating for other reasons. I filed 8168076 [1] to track
this. Let me know if this something that would help your specific case,
or not.

For your 'base' handler, is it possible that you deploy it as a service
on the application class path ( using the new provider mechanism ), and
have it provide the context sensitivity, based on TCCL or some such?
The frameworks could register with it, and it could use the future API
envisioned by 8168076 to delegate to the JDK's built-in handlers when 
needed.

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8168076

On 13/10/16 16:46, Thomas Watson wrote:
> Now that jigsaw is prohibiting deep reflection on types provided by the
> boot modules we are running into an issue with the ugly things we do [1]
> in order to support multiple factories in Equinox (an OSGi
> implementation).  Each Equinox instance has its own context aware
> ContentHandlerFactory and URLStreamHandlerFactory which serves up handlers
> that are available for the particular instance of Equinox.  In order to do
> this we have to resort to some very ugly reflection.  This allows us to
> gain access to the 'base' factory object set in the VM so that each
> instance of the framework can register itself with the 'base' factory. The
> 'base' factory handlers do the complicated work of figuring out which
> factory to call based on the context which is calling the base handler.
>
> We also resort to reflection on framework shutdown in order to flush our
> factories out from the VM so that the base factory is not pinning our
> framework in memory.  I am also aware that the Apache Felix OSGi Framework
> implementation uses similar deep reflection in its implementation.  Are
> there any plans in Java 9 that will make this scenario easier to achieve
> without resorting to the use of deep reflection on the URL types from the
> VM?  If not, are there going to be command line options that will allow us
> to open up deep reflection of specific VM types as a compatibility mode
> until we can get a proper solution?
>
> At a minimum I think we need someway to unset the statically set handlers
> in the VM to avoid pinning our base factories.  I can think of other
> non-reflective ways to gain access to the base handler instance in order
> to register each framework instance with the base handler.  For example,
> the base factory could implement a specific protocol which allows a
> connection to register another framework.
>
> But we are still left with a delima of how to wrap the handlers returned
> by various framework factory instances from the base handlers.  All the
> interesting methods on java.net.URLStreamHandler are protected.  Even
> though the proxy base handler extends java.net.URLStreamHandler it is not
> allowed to call the protected methods on another instance of
> java.net.URLStreamHandler.  We resorted to deep reflection on the
> java.net.URLStreamHandler class methods to do that.  The
> java.net.URLStreamHandler class is not an interface so we cannot easily
> create proxy classes using java.lang.reflect.Proxy.
>
> Tom
>
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=502209
>
>