@Capturing results in mockit.internal.ClassFile$NotFoundException: Unable to find class file for org.gradle.internal.io.ClassLoaderObjectInputStream

[jwgish]

Using the following environment:
Gradle 3.5 Build time: 2017-04-10 13:37:25 UTC Revision: b762622
Groovy: 2.4.10
Ant: Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM: 1.8.0_121 (Oracle Corporation 25.121-b13)
OS: Mac OS X 10.12.5 x86_64
It's using jmockit 1.25 and junit 4.11

See bug at gradle/gradle#2358

Gradle engineer concluded this is an issue with jmockit:
"It [jmockit] instruments all classes loaded in the VM through an agent and then assumes that all these classes are visible from the test class. JMockit should be more lenient here and ignore subtypes which the test can never reference anyway. More specifically CapturedType#isToBeCaptured should check whether the current test class can actually see that subtype."

I notice you do have improvements to @Capturing in the latest release, but couldn't tell whether this issue has been addressed or not.

Thanks

[rliesenfeld]

"org.gradle" will be filtered out to avoid the problem.

BTW, that build.gradle file is unnecessarily complicating things. I simplified it to the following, and works fine:

apply plugin: 'java'

repositories {
  mavenLocal()
  mavenCentral()
}

dependencies {
  testCompile "org.jmockit:jmockit:1.34"
  testCompile "junit:junit:4.12"
}

[oehme]

This would mean that no one can use org.gradle classes in their unit tests if they want to use your mocking framework. I.e. Gradle plugins cannot be tested with JMockit anymore.

I encourage you to do a proper visibility-based fix.

[jwgish]

Although I see that this was closed, it seems there are unresolved issues, based on the back-and-forth discussion on the approach between gradle and jmockit. If it was resolved, what is the resolution?