java.lang.IllegalStateException: Could not initialize plugin: interface org.mockito.plugins.MockMaker (alternate: null)
Caused by: java.lang.IllegalStateException: Failed to load interface org.mockito.plugins.MockMaker implementation declared in java.lang.CompoundEnumeration#4158debd
Caused by: java.lang.reflect.InvocationTargetException
Caused by: org.mockito.exceptions.base.MockitoInitializationException:
Could not initialize inline Byte Buddy mock maker.
It appears as if your JDK does not supply a working agent attachment mechanism.
Java : 16
JVM vendor name : Oracle Corporation
JVM vendor version : 16.0.2+7-67
JVM name : Java HotSpot(TM) 64-Bit Server VM
JVM version : 16.0.2+7-67
JVM info : mixed mode, sharing
OS name : Mac OS X
OS version : 11.5
Caused by: java.lang.IllegalStateException: Could not self-attach to current VM using external process
Getting the above error on Maven 3.8.1 and JDK16.02 with Mockito 3.7.7, on a fresh setup and cannot figure out why. I have tried every Mockito version from 3.7 all the way to 3.11 to no avail.
These configurations however works on an older setup based on JDK15 on Windows 10 Pro.
Mockito core depends on a library called byte-buddy and this problem is mostly occurred when mockito doesn’t find a matching byte buddy jar version.
Find out the mockito core version your project is using. In eclipse, you can check in project build path by navigating to
Right click on project -> Properties -> Java build path -> Libraries tab
Search maven repository for that version of mockito core.
Look at the Compile Dependencies section. Note down the correct dependent version of byte-buddy and include in the project. If the jar is already included with some other version, override the version with this correct version.
Build the application and run the tests again. Your issue related to MockMaker must be solved by now.
In my case I was running with an old 1.8 JDK. As of this writing with the dependencies below, it has to be Java 11.
testImplementation(platform('org.junit:junit-bom:5.8.2'))
testImplementation('org.junit.jupiter:junit-jupiter')
testImplementation group: 'org.mockito', name: 'mockito-junit-jupiter', version: '4.2.0'
testImplementation group: 'org.mockito', name: 'mockito-inline', version: '4.2.0'
testRuntime('org.junit.jupiter:junit-jupiter-engine:5.8.2')
Related
Hi so i tried to build my project by running mvn clean install. Ideally, it'd build successfully since all my other team members can do so fine. It, however, says i'm running into test failures. This is the exact error log given:
Tests run: 22, Failures: 0, Errors: 22, Skipped: 0, Time elapsed: 0.739 sec <<< FAILURE! - in com.pic.resources.xxx() Time elapsed: 0.216 sec <<< ERROR!
org.mockito.exceptions.base.MockitoException:
Failed to release mocks
This should not happen unless you are using a third-part mock maker
at com.pic.resources.xxx.java:50)
Caused by: org.mockito.exceptions.base.MockitoException:
Mockito cannot mock this class: class com.pic.service.xxx.
If you're not sure why you're getting this error, please report to the mailing list.
Java : 1.8
JVM vendor name : AdoptOpenJDK
JVM vendor version : 25.242-b08
JVM name : OpenJDK 64-Bit Server VM
JVM version : 1.8.0_242-b08
JVM info : mixed mode
OS name : Mac OS X
OS version : 10.16
You are seeing this disclaimer because Mockito is configured to create inlined mocks.
You can learn about inline mocks and their limitations under item #39 of the Mockito class javadoc.
Underlying exception : org.mockito.exceptions.base.MockitoException: Could not modify all classes [class com.pic.service.xxx]
at com.pic.resources.xxx.setup(xxx.java:50)
Caused by: org.mockito.exceptions.base.MockitoException: Could not modify all classes [class com.pic.service.xxx]
at com.pic.resources.xxx.setup(xxx.java:50)
Caused by: java.lang.IllegalStateException:
Byte Buddy could not instrument all classes within the mock's type hierarchy
This problem should never occur for javac-compiled classes. This problem has been observed for classes that are:
- Compiled by older versions of scalac
- Classes that are part of the Android distribution
at com.pic.resources.xxx.setup(xxx.java:50)
Caused by: java.lang.SecurityException: class "com.bmc.auth.OnBehalfOfAuthenticationDetailsProvider"'s signer information does not match signer information of other classes in the same package
at
I have tried ALL the possible solutions i can think of
updated my JDK to 11 and changed the jdk version on intellij and pointed mvn to be to JDK 11
downgraded my JDK to 8 and did same step as 1) and added the right byte-buddy with an older version
upgraded to latest maven
cleared cache
used latest mockito version (then tried old mockito version and nothing happened)
running this in both intellij and the terminal didn't change anything. Even tried importing the right intellij settings. That didn't work
added byte-buddy dependency and made it the latest version
The only other possible cause of the problem is that I upgraded my Mac OS to Big Sur the other day and it screwed up my java run time, but I don't know if tht's a cause or not.
The underlying issue seems to be this:
java.lang.SecurityException: class "com.bmc.auth.OnBehalfOfAuthenticationDetailsProvider"'s signer information does not match signer information of other classes in the same package
It might be the case that you have a package-private type and sign your jars, this does not normally work as the type needs to be placed in the same package which breaks the signature.
I am facing an issue with my gradle project during migration to Gradle 5.1 from Gradle 4.10.2 :
Issue :
./gradlew clean build
> Task :subprojects:lib-abc-admin:compileJava FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':subprojects:lib-abc-admin:compileJava'.
> Could not resolve all files for configuration ':subprojects:lib-abc-admin:compileClasspath'.
> Could not find org.glassfish.jersey:jersey-bom:.
Required by:
project :subprojects:lib-abc-admin
BUILD FAILED in 2s
In previous version Gradle 4.10.2, this error was getting circumvented by the following switch:
enableFeaturePreview("IMPROVED_POM_SUPPORT")
But in gradle 5 this switch has been deprecated, seems like this doesn't work anymore and I am getting the errors.
Any alternatives / suggestions / solutions ?
Toolchain Details :
------------------------------------------------------------
Gradle 5.1
------------------------------------------------------------
Kotlin DSL: 1.1.0
Kotlin: 1.3.11
Groovy: 2.5.4
Ant: Apache Ant(TM) version 1.9.13 compiled on July 10 2018
JVM: 11.0.1 (Oracle Corporation 11.0.1+13-LTS)
OS: Linux 4.19.8-200.fc28.x86_64 amd64
From gradle issue:
Different approaches were tried for supporting BOMs.
In Gradle 5.0, through feedback from the community (see #4422), we ended up deciding on an explicit notation to import a BOM.
So you will need to update dependencies on modules that are BOMs to that notation.
See documentation for details.
And since the IMPROVED_POM_SUPPORT feature is now enabled by default, you can remove the enableFeaturePreview("IMPROVED_POM_SUPPORT") line from your settings.gradle(.kts)
I have imported the following libraries in Gradle:
compile group: 'org.jcuda', name: 'jcuda-natives', version: '0.9.2'
compile group: 'org.jcuda', name: 'jcublas-natives', version: '0.9.2'
compile group: 'org.jcuda', name: 'jcublas', version: '0.9.2'
and copy pasted JCublasSampleexample from JCuda page.
Unfortunately, I am getting the following error:
Creating input data...
Performing Sgemm with Java...
Performing Sgemm with JCublas...
Exception in thread "main" java.lang.UnsatisfiedLinkError: Error while loading native library "JCudaRuntime-0.9.2-windows-x86_64"
Operating system name: Windows 10
Architecture : amd64
Architecture bit size: 64
---(start of nested stack traces)---
Stack trace from the attempt to load the library as a file:
java.lang.UnsatisfiedLinkError: no JCudaRuntime-0.9.2-windows-x86_64 in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at jcuda.LibUtils.loadLibrary(LibUtils.java:143)
at jcuda.runtime.JCuda.initialize(JCuda.java:422)
at jcuda.runtime.JCuda.<clinit>(JCuda.java:406)
at jcuda.jcublas.JCublas.initialize(JCublas.java:93)
at jcuda.jcublas.JCublas.<clinit>(JCublas.java:81)
...
Of course, library is absent. The question is how to link it Maven/Gradle? Site says all DLLs should be inside JARs.
CUDA is installed, but I didn't specify it's version anywhere as I was to do with nd4j.
It was my fault: cublas DLL of correct CUDA version was not in the PATH. DLL of JCublas was loading successfully without any Gradle tricks, because code was copying it into tmp directory froume CLASSPATH. Simultaneously, error message was not informative, suggesting me to look for problems in other place and also Gradle example was confusing.
Summarizing what is required: to have CUDA of the same version as JCublas installed (and PATH correct) and required "native" JARs on classpath.
I want to use 2 libraries that have been built with different and incompatible versions of JiBX.
Lib #1 runs with JiBX Runtime 1.0.1
Lib #2 runs with JiBX Runtime 1.2.6
The current version number is coded in the interface : org.jibx.runtime.IBindingFactory#CURRENT_VERSION_NUMBER .
When calling org.jibx.runtime.BindingDirectory#getFactory(), there's a compatibility test.
If the generated class and the runtime are incompatible, we got an exception like this :
Caused by: org.jibx.runtime.JiBXException: Binding information for
class Xxxx must be
regenerated with current binding compiler at
org.jibx.runtime.BindingDirectory.getFactoryFromName(Unknown Source)
at org.jibx.runtime.BindingDirectory.getFactory(Unknown Source)
EDIT - 29/07/2015
Another possible exception :
Caused by: org.jibx.runtime.JiBXException: Binding information for
class
Yyyyy must
be recompiled with current binding compiler (compiled with jibx_1_0_1,
runtime is jibx_1_2_5_SNAPSHOT) at
org.jibx.runtime.BindingDirectory.getFactoryFromName(BindingDirectory.java:125)
at
org.jibx.runtime.BindingDirectory.getFactory(BindingDirectory.java:178)
at
org.jibx.runtime.BindingDirectory.getFactory(BindingDirectory.java:197)
Is it possible to make it work ?
I've looked at the doc about JiBX Runtime but didn't found anything.
JiBX Runtime on Maven Central Repo.
I am using maven integration of sonar. My server is set up and running properly, and i am able to see the report in the browser, as well as violations in Eclipse.
My problem is i want to run the local analysis in Eclipse so that i can refactor the violations and see the change dynamically is eclipse itself.
But the local analysis fails and shows the below mentioned trace.
Runner configuration file: NONE<br>
Project configuration file: NONE<br>
Runner version: 2.0<br>
Java version: 1.6.0_41, vendor: Sun Microsystems Inc.<br>
OS name: "Windows 7", version: "6.1", arch: "amd64"<br>
Default locale: "en_US", source code encoding: "Cp1252"<br>
Server: [http://localhost:9000]<br>
Work directory: C:\dev\UPS Eclipse<br>
workspace\ips\.metadata\.plugins\org.eclipse.core.resources\.projects\ips-client\org.sonar.ide.eclipse.core<br>
Total time: 8.058s<br>
Exception in thread "main" org.sonar.runner.RunnerException: org.sonar.runner.RunnerException: No files matching pattern "dhbcore.jar" in directory "C:\Users\sg0213152\.m2\repository\com\ibm\com.ibm.dhbcore\7.5.0.0"<br>
at org.sonar.runner.Runner.delegateExecution(Runner.java:288)<br>
at org.sonar.runner.Runner.execute(Runner.java:151)<br>
at org.sonar.runner.Main.execute(Main.java:84)<br>
at org.sonar.runner.Main.main(Main.java:56)<br>
Caused by: org.sonar.runner.RunnerException: No files matching pattern "dhbcore.jar" in directory "C:\Users\sg0213152\.m2\repository\com\ibm\com.ibm.dhbcore\7.5.0.0"<br>
at org.sonar.runner.internal.batch.SonarProjectBuilder.getLibraries(SonarProjectBuilder.java:440)<br>
at org.sonar.runner.internal.batch.SonarProjectBuilder.cleanAndCheckModuleProperties(SonarProjectBuilder.java:327)<br>
at org.sonar.runner.internal.batch.SonarProjectBuilder.cleanAndCheckProjectDefinitions(SonarProjectBuilder.java:305)<br>
at org.sonar.runner.internal.batch.SonarProjectBuilder.generateProjectDefinition(SonarProjectBuilder.java:123)<br>
at org.sonar.runner.internal.batch.Launcher.execute(Launcher.java:58)<br>
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br>
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)<br>
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)<br>
at java.lang.reflect.Method.invoke(Method.java:597)<br>
at org.sonar.runner.Runner.delegateExecution(Runner.java:285)<br>
... 3 more<br>
Final Memory: 1M/120M<br>
P.S: I have the jar named 'com.ibm.dhbcore-7.5.0.0' already present in the specified location. Also, if i rename this file to the exact string that it is searching for, it then shows that some other jar is missing. I tried doing that for about 10-15 jars till i finally gave up.
Versions:
Eclipse: Juno
Sonar: 3.4.1
Sonar Java Analyzer (plugin for eclipse): 3.0
Solution - Upgraded SonarQube to the latest version
Upgraded SonarQube to 3.7.2
Upgraded Sonar Java Analyzer to 3.2.0
Please check your project settings in Eclipse, especially "Java Build Path" => "Libraries". You should have invalid entries like "C:\Users\sg0213152.m2\repository\com\ibm\com.ibm.dhbcore\7.5.0.0\dhbcore.jar"
You can also try to use a more recent version of SonarQube Eclipse (but that may force you to upgrade also your SonarQube server). We have added existence check before adding file in sonar.libraries to protect against invalid Eclipse classpath.