On 13/10/2016 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.
Have you looked at the changes in this area in JDK 9, specifically the
changes on how protocol handlers are located and the new URL stream
handler service-provider type URLStreamHandlerProvider?
-Alan
