mockito: Exception when using mock-maker-inline

I was trying out mock-maker-inline feature with the following example:

import static org.mockito.Mockito.*;

final class FinalClass {
  int m1() {
    throw new RuntimeException("42");
  }
}

public class TestMockFinal {
  public static void main(String[] args) {
    FinalClass cl = mock(FinalClass.class);
    when(cl.m1()).thenReturn(-1);
    if (cl.m1() != -1) {
      throw new Error("Not mocked!");
    }
  }
}

When I run this code I get the following error:

Exception in thread "main" java.lang.ExceptionInInitializerError
	at org.mockito.internal.util.MockUtil.<clinit>(MockUtil.java:24)
	at org.mockito.internal.util.MockCreationValidator.validateType(MockCreationValidator.java:22)
	at org.mockito.internal.creation.MockSettingsImpl.validatedSettings(MockSettingsImpl.java:168)
	at org.mockito.internal.creation.MockSettingsImpl.confirm(MockSettingsImpl.java:162)
	at org.mockito.internal.MockitoCore.mock(MockitoCore.java:64)
	at org.mockito.Mockito.mock(Mockito.java:1665)
	at org.mockito.Mockito.mock(Mockito.java:1578)
	at TestMockFinal.main(TestMockFinal.java:11)
Caused by: java.lang.IllegalStateException: Failed to load interface org.mockito.plugins.MockMaker implementation declared in sun.misc.CompoundEnumeration@379619aa
	at org.mockito.internal.configuration.plugins.PluginLoader.loadImpl(PluginLoader.java:86)
	at org.mockito.internal.configuration.plugins.PluginLoader.loadPlugin(PluginLoader.java:40)
	at org.mockito.internal.configuration.plugins.PluginRegistry.<init>(PluginRegistry.java:18)
	at org.mockito.internal.configuration.plugins.Plugins.<clinit>(Plugins.java:17)
	... 8 more
Caused by: java.lang.IllegalStateException: Error during attachment using: ByteBuddyAgent.AttachmentProvider.Compound{attachmentProviders=[ByteBuddyAgent.AttachmentProvider.ForJigsawVm.INSTANCE, ByteBuddyAgent.AttachmentProvider.ForJ9Vm.INSTANCE, ByteBuddyAgent.AttachmentProvider.ForToolsJarVm.JVM_ROOT, ByteBuddyAgent.AttachmentProvider.ForToolsJarVm.JDK_ROOT, ByteBuddyAgent.AttachmentProvider.ForToolsJarVm.MACINTOSH]}
	at net.bytebuddy.agent.ByteBuddyAgent.install(ByteBuddyAgent.java:314)
	at net.bytebuddy.agent.ByteBuddyAgent.install(ByteBuddyAgent.java:280)
	at net.bytebuddy.agent.ByteBuddyAgent.install(ByteBuddyAgent.java:248)
	at net.bytebuddy.agent.ByteBuddyAgent.install(ByteBuddyAgent.java:234)
	at org.mockito.internal.creation.bytebuddy.InlineByteBuddyMockMaker.<init>(InlineByteBuddyMockMaker.java:101)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at java.lang.Class.newInstance(Class.java:442)
	at org.mockito.internal.configuration.plugins.PluginLoader.loadImpl(PluginLoader.java:81)
	... 11 more
Caused by: java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at net.bytebuddy.agent.ByteBuddyAgent.install(ByteBuddyAgent.java:301)
	... 21 more
Caused by: com.sun.tools.attach.AttachNotSupportedException: no providers installed
	at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:208)
	... 26 more

Environment:

Windows 7 (64 bit)
JDK 1.8.0_112 (64 bit)

java version "1.8.0_112"
Java(TM) SE Runtime Environment (build 1.8.0_112-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)

Mockito 2.3.4
ByteBuddy 1.5.5 (transitive from Mockito)

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 16 (16 by maintainers)

Most upvoted comments

I just debugged this on a virtual Windows box and I think I understand what happens:

First, everything went as expected. I could run the program and did not get the exception you experienced. I then installed an additional non-JDK JVM to see if the VM reproduced your problem. This was the case and I thought, this was your problem for sure.

To be certain, I retried it now with the JDK installation and it did no longer work. To my surprise, the installation had set some ..\ProgramData\Oracle\Java\... folder in my user’s hidden folder and overrode the JAVA_HOME property even if I set it to the proper place. I had to manually remove this folder and adjust my Windows PATH before I could run the above program with the installation specified at JAVA_HOME. Now, I could again switch between JDK and JVM.

The best part is that even without doing this, java -version shows the value of JAVA_HOME, thus indicates that you are running a JDK, not the JVM that you actually run. If you call System.gerProperty("java.home") from a program you run with the very same java.exe, you can however see the actual value.

The longer exception you see is a small issue in Byte Buddy that does however not change the outcome of the attachment. On Unix, if no JDK is available, Byte Buddy attempts to use its own attachment implementation. On Windows, this is impossible and would result in another IllegalStateException.

raphw on Dec 16, 2016

@raphw you are absolutely right!

If I print JAVA_HOME variable I get:

P:\>echo %JAVA_HOME%
c:\Program Files\Java\jdk1.8.0_112\

But when I run test program which prints System.getProperty("java.home") I get the following:

java.home=C:\Program Files\Java\jre1.8.0_112

This happens, because I’m always installing JDK with JRE from the same installer. Installer first installs JDK and then installs JRE. What I do then is set JAVA_HOME to point to newly installed JDK and always include JAVA_HOME\bin into PATH variable. However when I print PATH variable I see the following:

P:\>echo %PATH%
C:\ProgramData\Oracle\Java\javapath
...
c:\Program Files\Java\jdk1.8.0_112\\bin
...

The very first entry is this magic C:\ProgramData\Oracle\Java\javapath which is apparently breaking everything.

vyazelenko on Dec 16, 2016