8000 IllegalStateException in JavaModuleLayerModification · Issue #418 · eclipse-efx/efxclipse-rt · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
8000

IllegalStateException in JavaModuleLayerModification #418

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
cdamus opened this issue Nov 11, 2020 · 3 comments
Open

IllegalStateException in JavaModuleLayerModification #418

cdamus opened this issue Nov 11, 2020 · 3 comments

Comments

@cdamus
Copy link
cdamus commented Nov 11, 2020 •
edited
Loading

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 the FXClassLoader 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:

  • a system property (e.g. -Dorg.eclipse.fx.osgi.modulemodification.disabled=true) to opt out of the JavaModuleLayerModification processing of reads/exports/opens directives in bundle manifests. By default it is enabled with false
  • remember attempted module modifications that failed, to not try them again, thus cutting off the flood of exceptions on stderr
  • use the JPMS API to check whether the attempted module modification can be expected to work: the case here is an attempt to modify a module that already is in a layer, so can the JavaModuleLayerModification class first check whether that is so?
  • an elaboration of the previous item: in my application, is use --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 the JavaModuleLayerModification redundant, so perhaps it could check whether a modification it would attempt is redundant for such reason?

The exception:

FXClassLoader#collectModifications - Reads: []
FXClassLoader#collectModifications - Exports: [javafx.graphics/com.sun.javafx.scene=BUNDLE(@150), javafx.graphics/com.sun.javafx.application=BUNDLE(@164), javafx.graphics/com.sun.glass.ui=BUNDLE(@164)]
FXClassLoader#collectModifications - Opens: [javafx.graphics/javafx.scene=BUNDLE(@150)]
FXClassLoader#advancedModuleLayerBoostrap - Using advanced layer creation to apply patches
JavaModuleLayerModification#applyConfigurations - Exporting 'javafx.graphics/com.sun.javafx.scene=BUNDLE(@150)'
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
	at org.eclipse.fx.osgi.fxloader.jpms.ModuleLayerWrapper$ControllerWrapper.addExports(ModuleLayerWrapper.java:173)
	at org.eclipse.fx.osgi.fxloader.jpms.JavaModuleLayerModification.applyConfigurations(JavaModuleLayerModification.java:110)
	at org.eclipse.fx.osgi.fxloader.FXClassLoader.advancedModuleLayerBoostrap(FXClassLoader.java:483)
	at org.eclipse.fx.osgi.fxloader.FXClassLoader.initModuleLayer(FXClassLoader.java:426)
	at org.eclipse.fx.osgi.fxloader.FXClassLoader.getModuleLayer(FXClassLoader.java:293)
	at org.eclipse.fx.osgi.fxloader.FXClassLoader.findClassJavaFX11(FXClassLoader.java:207)
	at org.eclipse.fx.osgi.fxloader.FXClassLoader.postFindClass(FXClassLoader.java:144)
	at org.eclipse.osgi.internal.loader.BundleLoader.searchHooks(BundleLoader.java:530)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:493)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:425)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:417)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:171)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Class.java:398)
	at java.xml/javax.xml.parsers.FactoryFinder.getProviderClass(FactoryFinder.java:108)
	at java.xml/javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:183)
	at java.xml/javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:147)
	at java.xml/javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:271)
	at java.xml/javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:147)
	at org.eclipse.osgi.internal.framework.XMLParsingServiceFactory.createService(XMLParsingServiceFactory.java:59)
	at org.eclipse.osgi.internal.framework.XMLParsingServiceFactory.getService(XMLParsingServiceFactory.java:51)
	...
Caused by: java.lang.IllegalArgumentException: module javafx.graphics not in layer
	at java.base/java.lang.ModuleLayer$Controller.ensureInLayer(ModuleLayer.java:216)
	at java.base/java.lang.ModuleLayer$Controller.addExports(ModuleLayer.java:268)
	... 168 more
@cdamus
Copy link
Author
cdamus commented Nov 11, 2020

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.

@tomsontom
Copy link
Contributor

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.

@cdamus
Copy link
Author
cdamus commented Nov 11, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tomsontom @cdamus
0