Rafael Winterhalter

Can you run with `-Dnet.bytebuddy.dump=/some/folder` and attach the class in question before and after?

Does this still happen with a more recent Mockito? As for https://github.com/raphw/byte-buddy/issues/1047, you simply need to specify a folder that exists when running your tests.

You might not be able to distinguish them. The inline mock maker changes byte code and not layout/subclasses, this is how it works in the first place. Try: Mockito.mockingDetails(factoryA).isMock(); Mockito.mockingDetails(factoryB).isMock();...

The problem is, that from the inside of the mock, we do not know what `getT()` returns. We only know the erasure, where `Object` would be returned. But javac adds...

I assume that you are running a JVM and not a JDK on Windows. Did you check your `PATH` variable and your `JAVA_HOME`? The JVM complains that no attachment providers...

It seems like attachment does not work as it cannot locate tools.jar. Is your `java.home` property set correctly?

That is strange as the exceptions root seems to come from the JVM: Caused by: com.sun.tools.attach.AttachNotSupportedException: no providers installed I have no idea how this can be caused by using...

Ok, it seems like the JMockit library copied some classes from the VM into its jar file and this blows up the attachment attempt as Byte Buddy (and therefore Mockito)...

Did you try to add the tools jar dependencies? I am wondering if this is another JAVA_HOME issue. Could you check if there is a tools.jar file in the Docker...

Byte Buddy is using the `java.home` system property. It looks at several knwon relative locations from there: https://github.com/raphw/byte-buddy/blob/master/byte-buddy-agent/src/main/java/net/bytebuddy/agent/ByteBuddyAgent.java#L822 Maybe the file is not readable to the JVM process or something...