I am trying to resurrect, just for a brief moment, some very old Java 7 code in a modern Eclipse 2022-06 IDE. The software made extensive use of the com.sun.media.sound package, in particular WaveFileWriter. It did some manipulations at the numeric level to create sound effects, and I have no wish to go re-write the thing for something I only need to use once, for five minutes, and forget about it.
However, com.sun.media.sound now works very badly, and even opening the file gives me this error:
Exception in thread "main" java.lang.IllegalAccessError: class [DO THE STUFF] (in unnamed module #0x6615435c) cannot access class com.sun.media.sound.WaveFileWriter (in module java.desktop) because module java.desktop does not export com.sun.media.sound to unnamed module #0x6615435c
I am very confused by this-- Per this question, this error appears to be related to JDK9, but this code was written before JDK9, and the build path in Eclipse appears to be JDK7 as well.
I am certain something is misconfigured in Eclipse, but I have no idea what.
I'm trying to use the spire.office.free library to manage office files from java. For this I have a project using spring tool suite with maven for the download of that library. The problem is that when I run the code I get the following error.
Exception in thread "main" java.lang.IllegalAccessError: class com.spire.office.packages.sprkzh (in unnamed module #0x29647f75) cannot access class sun.security.action.GetPropertyAction (in module java.base) because module java.base does not export sun.security.action to unnamed module #0x29647f75
at com.spire.office.packages.sprkzh.spr??(Unknown Source)
at com.spire.office.packages.sprkzh.spr??(Unknown Source)
at com.spire.office.packages.sprkzh.<init>(Unknown Source)
at com.spire.office.packages.sprfqg.<init>(Unknown Source)
at com.spire.office.packages.sprhqg.<init>(Unknown Source)
at com.spire.xls.core.spreadsheet.XlsWorkbook.<init>(Unknown Source)
at com.spire.xls.Workbook.<init>(Unknown Source)
at Eu.Extrae.Principal.main(Principal.java:21)
At this moment java console informs me that it is not able to access the code of the library
Class file editor
The curious thing about the matter is that if I download the spire.office.free and use it as an external library the problem disappears and everything works correctly.
I know that is a solution to the problem but I prefer to use maven in any case
Any solution?
Thanks in advance
You muss download and add Jar file. I have this problem with excel, and I added the jar build path/configure build pat/maven dependencies and add the downloaded jar and problem solved
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'm trying to transform the following library into Java 9 module: https://github.com/sskorol/test-data-supplier
Followed this guide: https://guides.gradle.org/building-java-9-modules
After some manipulations and refactoring (couldn't manage lombok issues, so just temporary removed it), I have the following module-info.java:
module io.github.sskorol {
exports io.github.sskorol.core;
exports io.github.sskorol.model;
requires testng;
requires vavr;
requires streamex;
requires joor;
requires aspectjrt;
}
And it even compiles / builds in case of tests' skipping.
However, when I try to run a test task, I'm getting the following exception:
org.gradle.api.internal.tasks.testing.TestSuiteExecutionException: Could not complete execution for Gradle Test Executor 2.
at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:63)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy1.stop(Unknown Source)
at org.gradle.api.internal.tasks.testing.worker.TestWorker.stop(TestWorker.java:120)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:146)
at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:128)
at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: org.testng.TestNGException:
Cannot instantiate class io.github.sskorol.testcases.DataSupplierTests
at testng#6.11/org.testng.internal.ObjectFactoryImpl.newInstance(ObjectFactoryImpl.java:31)
at testng#6.11/org.testng.internal.ClassHelper.createInstance1(ClassHelper.java:410)
at testng#6.11/org.testng.internal.ClassHelper.createInstance(ClassHelper.java:323)
at testng#6.11/org.testng.internal.ClassImpl.getDefaultInstance(ClassImpl.java:126)
at testng#6.11/org.testng.internal.ClassImpl.getInstances(ClassImpl.java:191)
at testng#6.11/org.testng.TestClass.getInstances(TestClass.java:99)
at testng#6.11/org.testng.TestClass.initTestClassesAndInstances(TestClass.java:85)
at testng#6.11/org.testng.TestClass.init(TestClass.java:77)
at testng#6.11/org.testng.TestClass.<init>(TestClass.java:42)
at testng#6.11/org.testng.TestRunner.initMethods(TestRunner.java:423)
at testng#6.11/org.testng.TestRunner.init(TestRunner.java:250)
at testng#6.11/org.testng.TestRunner.init(TestRunner.java:220)
at testng#6.11/org.testng.TestRunner.<init>(TestRunner.java:161)
at testng#6.11/org.testng.SuiteRunner$DefaultTestRunnerFactory.newTestRunner(SuiteRunner.java:578)
at testng#6.11/org.testng.SuiteRunner.init(SuiteRunner.java:185)
at testng#6.11/org.testng.SuiteRunner.<init>(SuiteRunner.java:131)
at testng#6.11/org.testng.TestNG.createSuiteRunner(TestNG.java:1383)
at testng#6.11/org.testng.TestNG.createSuiteRunners(TestNG.java:1363)
at testng#6.11/org.testng.TestNG.runSuitesLocally(TestNG.java:1217)
at testng#6.11/org.testng.TestNG.runSuites(TestNG.java:1144)
at testng#6.11/org.testng.TestNG.run(TestNG.java:1115)
at org.gradle.api.internal.tasks.testing.testng.TestNGTestClassProcessor.runTests(TestNGTestClassProcessor.java:129)
at org.gradle.api.internal.tasks.testing.testng.TestNGTestClassProcessor.stop(TestNGTestClassProcessor.java:88)
at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:61)
... 25 more
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make public io.github.sskorol.testcases.DataSupplierTests() accessible: module io.github.sskorol does not "exports io.github.sskorol.testcases" to module testng
at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:337)
at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:281)
at java.base/java.lang.reflect.Constructor.checkCanSetAccessible(Constructor.java:192)
at java.base/java.lang.reflect.Constructor.setAccessible(Constructor.java:185)
at testng#6.11/org.testng.internal.ObjectFactoryImpl.newInstance(ObjectFactoryImpl.java:22)
... 48 more
It seems a bit confusing to me, as io.github.sskorol.testcases is a part of src/test/java and there's no module-info for tests. So I can't export this package to TestNG. Have an assumption that the root cause in a TestNG reflection usage within ObjectFactoryImpl against test classes.
Does anyone have any idea how to workaround it?
Environment: JDK 9 (build 9+181), Gradle 4.1, TestNG 6.11
Have an assumption that the root cause in a TestNG reflection usage within ObjectFactoryImpl against test classes.
It's one of two causes, yes. The other is that, apparently, Gradle runs your tests as a module. As you point out, there's no module descriptor for your tests. Gradle may use --patch-module to add the tests to the module containing the production code.
This question and answer provides a lot of background information and possible fixes. As a short term fix, I recommend to add opens io.github.sskorol.testcases to your production code's module descriptor. Judging by its name, I'd guess there is no such package yet, so you'd either have to rename or add a dummy class (I would prefer the former).
I would also take this issue to a Gradle mailing list or bug tracker. Unless we've overlooked something (entirely possible), Gradle's behavior is very unfortunate because it would require adapting the production code's module descriptor to the test code's needs.
If the tests are in the same package as the module under test then they need to be compiled (with --patch-module) so that they are compiled "as if" they are part of the module. The references to TestNG types in the tests means that that --add-reads io.github.sskorol=testng will be needed too.
Running is similar. The tests need to be run "as if" they are in module io.github.sskorol. This means running with:
--patch-module io.github.sskorol=<testclasses> \
--add-reads io.github.sskorol=testng
Additionally, you may need to export or open the packages with the tests to TestNG. This will come down to whether the test classes and methods are public in an exported package. To avoid scanning, the simplest is to open the all packages containing tests to TestNG, e.g.
--add-opens io.github.sskorol/io.github.sskorol.core=testng \
--add-opens io.github.sskorol/io.github.sskorol.core.internal=testng
(.internal is just a filler for a non-exported package in the module)
All this might look complicated but it's something that the Maven Surefire plugin and also Gradle should do.
Did some tricks suggested by #AlanBateman, who gave me a valid direction.
Finally, I came up with the following configuration:
module-info.java
module io.github.sskorol {
exports io.github.sskorol.core;
exports io.github.sskorol.model;
opens io.github.sskorol.utils to joor;
requires testng;
requires vavr;
requires streamex;
requires joor;
}
build.gradle
test {
inputs.property("moduleName", moduleName)
doFirst {
jvmArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'ALL-MODULE-PATH',
'--add-opens', 'io.github.sskorol/io.github.sskorol.testcases=testng',
'--add-opens', 'io.github.sskorol/io.github.sskorol.testcases=joor',
'--add-opens', 'io.github.sskorol/io.github.sskorol.datasuppliers=joor',
'--add-opens', 'io.github.sskorol/io.github.sskorol.datasuppliers=testng',
'--add-opens', 'java.base/java.util=streamex',
'--add-opens', 'java.base/java.util.stream=streamex',
'--patch-module', "$moduleName=" + files(sourceSets.test.java.outputDir).asPath
]
classpath = files()
}
}
Both testng and joor required access to my test packages. So --add-opens flag did the trick. streamex module also had concerns accessing java.base packages.
Note that in comparison with original Java 8 code I had to remove lombok and aspectj dependencies, as I couldn't manage to fully resolve all the issues occurred after migration.
Another problem I've faced with was related to SPI testing. According to docs I've read, in Java 9 SPI implementations should be listed within module-info.java instead of META-INF/services. But it doesn't seem to be a solution, when implementation class is located in one of test packages, as again test is not a module. Just wondering if there's some jvmflag for replacing provides ... with ... syntax, and doing the same trick as with --add-opens. Any thoughts would be appreciated.
Full implementation, modified to support Java 9, could be found here.