|Re: [equinox-dev] Equinox, PDE and packages from the ExtensionClasspath (e.g. JavaFX)|
I agree that the most simple option is to change the launcher to use the app class loader as the parent classloader. The default for that has been boot for many years. This has provided us with a level of isolation from the extension and application class loaders. We could change the default, but I don't think that has no risk associated with it.
I had not thought about the fact that frameworks must fail to install extension bundles with types they do not understand. So it is true that this fragment will fail to install on other frameworks (if they are performing the proper check). In equinox we treat the extension type extclasspath as a special type and for packages exported by such a fragment we delegate class loads to the extension class loader no matter what the parent class loader of the framework is. So it should not matter what the framework's class path is in this case. But don't get me wrong. I would much prefer we did not use this option. In fact I don't even really want to support such a concept of extension system bundle fragments at all in the future since I think it will be difficult to support them if we start running with Java Modularity support in the VM.
Even if we do change the default of the framework's parent class loader, we still need a way to configure the system bundle to export the JavaFX packages.
BJ Hargrave---11/13/2012 04:47:16 PM---> > Fragment-Host: system.bundle; extension:=extclasspath >
From: BJ Hargrave/Austin/IBM@IBMUS
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
Date: 11/13/2012 04:47 PM
Subject: Re: [equinox-dev] Equinox, PDE and packages from the ExtensionClasspath (e.g. JavaFX)
Sent by: equinox-dev-bounces@xxxxxxxxxxx
office: +1 386 848 1781
mobile: +1 386 848 3788