Building dynamic Java Module System layers to integrate JavaFX 11 in Equinox

One of the most fundamental features of the e(fx)clipse runtime is to integrate JavaFX into the Equinox OSGi-Container and even a running Eclipse IDE. We currently support the following setups:

• JavaFX 8
• JavaFX 9/10
• JavaFX 11

and the integration for all those versions is a bit different. I don't want to go into details but starting with JavaFX-11 we need to spin up a new Java-Module-System-Layer at runtime because we can not assume JavaFX being part of the JRE running your OSGi-Container (Eclipse IDE). Since JavaFX-9 we spin up a dynamic layer to implement JavaFX-SWT-Integration and we adapted that logic for JavaFX-11 to load all JavaFX-11 modules. The code we have works like this and it works prefectly fine until someone like ControlsFX comes along and does not play by the rules trying to load classes from unexported packages like com.sun.javafx.runtime.VersionInfo. The standard answer from ControlsFX to fix that problem temporarily is to force the module-system to export them using --add-exports=javafx.base/com.sun.javafx.runtime=ALL-UNNAMED. Unfortunately this workaround does not work in our case because the command-line flag only allows to modify modules of the Boot-Layer but not those created in dynamic ones like those we construct inside our JavaFX-OSGi integration. I was investigating yesterday how one could fix this problem but could not come up with a good solution (one that does not call into internals of the module system) until I tweeted about it and Tom Watson (one of the maintainers of Equinox) pointed me into the right direction. So the solution is and now I have to think how we expose that to in our OSGi-Integration.