java.lang.ClassCastException: class sun.font.CompositeFont cannot be cast to class sun.font.PhysicalFont (sun.font.CompositeFont and sun.font.PhysicalFont are in module java.desktop of loader 'bootstrap')
java.desktop/sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1086)
java.desktop/sun.font.SunFontManager.initialiseDeferredFont(SunFontManager.java:965)
java.desktop/sun.font.SunFontManager.initialiseDeferredFonts(SunFontManager.java:831)
java.desktop/sun.font.SunFontManager.loadFonts(SunFontManager.java:3182)
java.desktop/sun.awt.X11FontManager.loadFonts(X11FontManager.java:438)
java.desktop/sun.font.SunFontManager.getAllInstalledFonts(SunFontManager.java:3543)
java.desktop/sun.java2d.SunGraphicsEnvironment.getAllFonts(SunGraphicsEnvironment.java:209)
java.desktop/sun.java2d.HeadlessGraphicsEnvironment.getAllFonts(HeadlessGraphicsEnvironment.java:72)
I have openjdk11 in my Centos server. I have seen this issue fixed by installing fontconfig package in os. Is there a way that i can fix this issue without installing any package?
I tried to copy some the fontconfig.properties files in my $JAVA_HOME/lib/ folder
Related
My source code compiles on java 7 and runs on java 11.
I am trying to integrate imperva RASP as a java agent in tomcat. However, when I start the tomcat server, it is throwing following exception:
Caused by: java.lang.IllegalAccessError: class sun.security.ec.ECDSASignature (in module jdk.crypto.ec) cannot access class com.imperva.rasp.AgentBridge (in unnamed module #0x66c61024) because module jdk.crypto.ec does not read unnamed module #0x66c61024
at jdk.crypto.ec/sun.security.ec.ECDSASignature.<init>(ECDSASignature.java:118)
at jdk.crypto.ec/sun.security.ec.ECDSASignature.<init>(ECDSASignature.java:106)
at jdk.crypto.ec/sun.security.ec.ECDSASignature$SHA1.<init>(ECDSASignature.java:214)
at jdk.crypto.ec/sun.security.ec.SunEC$ProviderService.newInstance(SunEC.java:102)
at java.base/java.security.Signature.isSpi(Signature.java:331)
The way I am passing java agent is:
JAVA_OPTS="-javaagent:$IMPERVA_JAR $JAVA_OPTS"
I went through multiple posts such as this one about --add-opens argument. Based on that, I am passing JDK_JAVA_OPTIONS="$JDK_JAVA_OPTIONS --add-opens=jdk.crypto.ec/sun.security.ec=ALL-UNNAMED"
I can see following statement in the logs:
Picked up JDK_JAVA_OPTIONS: --add-opens=jdk.crypto.ec/sun.security.ec=ALL-UNNAMED
Am I missing something here or is there any syntax error in the arguments that I am passing?
There is no any other configuration is done.
Any help is appreciated. Thank you.
Managed to solve it by using --add-reads instead of --add-opens.
JDK_JAVA_OPTIONS="$JDK_JAVA_OPTIONS --add-reads jdk.crypto.ec=ALL-UNNAMED"
I am new to the OSGi concept, and any help is appreciated on the below error.
When running the standalone application there are no issues but when the same application is put inside the OSGI bundle we are getting the below error.
Cause exception java.lang.RuntimeException: Could not instantiate
parser org.apache.xerces.parsers.SAXParser:
java.lang.ClassCastException: class
org.apache.xerces.parsers.SAXParser cannot be cast to class
org.xml.sax.Parser (org.apache.xerces.parsers.SAXParser is in unnamed
module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader
#14b4fcf0; org.xml.sax.Parser is in unnamed module of loader
org.eclipse.osgi.internal.loader.EquinoxClassLoader #555c2470)
Please note, the code snippet works with JRE8 + Eclipse 4.4 but failed with the above error with JRE 11 + Eclipse 4.19.
In my application, I am invoking the third-party API, which internally tries to do the above casting, and throws an error.
I understood that this is something related to the OSGi class loader, but need steps to find the cause of this issue. We tried to get more information through the OSGi console as it's a huge application, I can see more than 1000 bundles listed if we execute the SS command on the console.
Thanks in advance.
Regards,
Hrushi
This is due to the changes within Java 9 (Jigsaw). See https://www.logicbig.com/tutorials/core-java-tutorial/modules/unnamed-modules.html.
We had similar issues in our product when upgrading to java 11. This has probably something to do with old libraries which export org.xml.sax somehow. We've upgraded or replaced those libraries to get it fixed
I am trying to run a minecraft modpack from Twitch. The modpack runs in minecraft version 12.2, so it uses the old minecraft launcher. When I try to launch it, the following is displayed in the game output:
'''
Exception in thread "main" java.lang.ClassCastException: class jdk.internal.loader.ClassLoaders$AppClassLoader cannot be cast to class java.net.URLClassLoader (jdk.internal.loader.ClassLoaders$AppClassLoader and java.net.URLClassLoader are in module java.base of loader 'bootstrap')
at net.minecraft.launchwrapper.Launch.(Launch.java:34)
at net.minecraft.launchwrapper.Launch.main(Launch.java:28)
'''
I was wondering what the error is and how I could go about fixing it.
please try it with another Java Version.
I think the Launcher is to Old for it...
I wanted to just run HelloWorld on Intellij Idea which is failed.
Java Version is "9-ea" in my macOS.
Error:Internal error: (java.lang.IllegalAccessError) class com.intellij.util.io.FileChannelUtil (in unnamed module #0x6ecc4cd7) cannot access class sun.nio.ch.FileChannelImpl (in module java.base) because module java.base does not export sun.nio.ch to unnamed module #0x6ecc4cd7
java.lang.IllegalAccessError: class com.intellij.util.io.FileChannelUtil (in unnamed module #0x6ecc4cd7) cannot access class sun.nio.ch.FileChannelImpl (in module java.base) because module java.base does not export sun.nio.ch to unnamed module #0x6ecc4cd7
at com.intellij.util.io.FileChannelUtil.setupUnInterruptibleHandle(FileChannelUtil.java:26)
......
Please make sure to use the release JDK version, not ea and update to the latest IntelliJ IDEA version.
I had the same error and the solution I've found was to downgrade my Java version (JDK) from 16 to 11. Then, it worked :)
We receive the follow exception in our test system. Any idea how we can prevent this exception for example with a command line switch. And any idea how this exception can occur?
Can the completely access check be disabled in a test system that use intensively reflection and class loading?
java.lang.IllegalAccessError: class java.io.File (in module java.base) cannot access class javax.print.PrintException (in module java.desktop) because module java.base does not read module java.desktop
at java.io.File.exists(File.java)
at jdk.internal.loader.URLClassPath$FileLoader.getResource(URLClassPath.java:1199)
at jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:314)
at jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:697)
at jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:623)
at jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.lang.ClassLoader.loadClass(ClassLoader.java:521)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:398)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:67)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
Try to run it by adding the following command argument.
--add-reads java.base=java.desktop
We solve the problem by updating JMockit version 1.31 with the current version 1.44. It look like the old version is not compatible with the current version.