Open cdamus opened 3 years ago
Continuing to analyze my problem, I have learned that the Equinox Hook Registry supports a system property specifying hooks to exclude, so I can use that in my application to exclude the FXClassloaderHookConfigurator
. That is better than leaving the org.eclipse.fx.osgi
bundle out of my configuration (which was unpractical for a few reasons) and may obviate this issue. But perhaps the class loader hook may still internally improve its robustness and provide its own specific controls so that it may continue to provide other functionality and applications needn't exclude it altogether.
well the only purpose of the hooks in a Java-11 world is to spin up a new JPMS-Layer so that one can deploy JavaFX with the application. The first question is why is the org.eclipse.fx.osgi
packaged at all?
We know which JPMS-Modules we've started up ourselves so we should be able to detect that we can't open up what we don't control.
Thanks, Tom. This bundle is packaged because it's included in the org.eclipse.fx.target.rcp4.feature
feature in which I get all the bits I need for my app. If there's a more appropriate feature to use, I could look at that, though it might complicate my software upgrade scenarios.
It wasn't clear to me from debugging this how it would be that a typical app deployment (mine may not be typical) is meant to instantiate JPMS modules in the OSGi context, especially when those modules are JavaFX. It sounds like you're suggesting a better way to avoid this exception than I've thought of so far, which is good.
In my RCP application, I bundle a Java 11 VM with JavaFX 14. At run-time, I get a continual flood of exceptions (quoted below) from attempts by the
JavaModuleLayerModification
to modify the exports and opens of JavaFX bundles as specified by a few declarations in e(fx)eclipse bundle manifests. I don't need these, so it would be nice either to be able to easily turn off this functionality or else stem the flood of exceptions. The exception is thrown seemingly every time the class loader is asked for a class that isn't in the JRE because theFXClassLoader
never completes its module modifications and so tries every time to do them, and fails.I think the root cause of the problem is that the JavaFX modules that the e(fx)eclipse is trying to modify are discovered as already being in the base layer, as I have packaged them in my JRE. So, the assertion that they are in the layer created by the
JavaModuleLayerModification
fails. It is simply not possible for e(fx)eclipse to modify these modules using the JPMS API.The work-around I am doing in my application for now is to exclude the
org.eclipse.fx.osgi
bundle from the package build because it only provides this class loader hook and I don't need that. However, this will be a problem when eventually the bundle gains more functionality.So, perhaps this issue can be addressed for the general case by any combination of:
-Dorg.eclipse.fx.osgi.modulemodification.disabled=true
) to opt out of theJavaModuleLayerModification
processing of reads/exports/opens directives in bundle manifests. By default it is enabled withfalse
stderr
JavaModuleLayerModification
class first check whether that is so?--add-exports
and--add-opens
on the command-line to export and open JavaFX internals to all unnamed modules (my application's OSGi bundles). These make the declarations processed by theJavaModuleLayerModification
redundant, so perhaps it could check whether a modification it would attempt is redundant for such reason?The exception: